Como publicar um app do Lovable na App Store: PWA, Capacitor ou reconstrução, e como evitar a 4.2 (2026)

Se você está procurando como publicar um app do Lovable na App Store, a primeira coisa a saber é que o Lovable não faz isso por você. A documentação de publicação do Lovable diz que "o Lovable cria web apps e a publicação sempre faz deploy para uma URL web" e que não existe "um fluxo integrado que empacote e envie seu projeto para a App Store ou o Google Play." A seguir estão as três opções reais, quanto cada uma custa e os passos que mantêm um app do Lovable empacotado longe da Diretriz 4.2.

Dá para publicar um app do Lovable direto na App Store?

Não. Em outubro de 2026, o Lovable publica em um subdomínio lovable.app ou em um domínio próprio, e entrar em uma loja significa empacotar o app fora do Lovable e enviá-lo pela sua própria conta de desenvolvedor.

A documentação do Lovable sugere duas alternativas: transformar o site publicado em um PWA instalável ou "envolver sua URL publicada em um shell nativo com Capacitor fora do Lovable" e enviar esse shell você mesmo. A documentação também deixa duas coisas claras. O Lovable não gera projetos React Native, e o app mobile do Lovable serve apenas para criar projetos pelo celular. Ele "não transforma seu projeto em um app nativo para usuários finais."

PWA, wrapper com Capacitor ou reconstrução: qual caminho escolher?

Escolha um PWA se você não precisa de página na loja, Capacitor se precisa de página na loja e consegue adicionar recursos nativos de verdade, e uma reconstrução nativa se o seu app precisa parecer e se comportar como um produto pensado para o celular.

As taxas vêm da página de inscrição do Apple Developer Program ("99 USD por ano de assinatura. Os preços podem variar por região") e da Ajuda do Google Play Console ("uma taxa única de registro de US$25"). No Google Play, novas contas pessoais também precisam fazer um teste fechado com 12 testadores por 14 dias antes de obter acesso à produção. Nosso guia de teste fechado cobre essa etapa.

Como empacotar um app do Lovable com Capacitor?

Exporte o código do Lovable para o GitHub, faça o build localmente, adicione o Capacitor e aponte webDir para a saída do build. Depois abra os projetos nativos no Xcode e no Android Studio e gere os arquivos.

1. No Lovable, conecte o GitHub. A sincronização é bidirecional e sempre cria um novo repositório privado, então você pode continuar editando no Lovable enquanto trabalha no shell nativo localmente.
2. Clone o repositório, rode npm install e depois npm run build. Verifique onde o Vite grava a saída, que normalmente é dist. O Capacitor precisa de um index.html com uma tag <head> nessa raiz.
3. Instale o Capacitor e as plataformas usando os comandos do bloco de código abaixo, tirados da documentação de primeiros passos do Capacitor.
4. Em capacitor.config, defina webDir como dist. Não defina server.url como seu domínio do Lovable em produção: a referência de configuração do Capacitor diz que ele "não se destina a uso em produção."
5. Adicione plugins nativos (push, haptics, compartilhamento, biometria, notificações locais) e ícones e splash screens nativos.
6. Rode npx cap sync depois de cada build web, então gere o archive no Xcode e faça o upload para o App Store Connect. Nosso checklist de envio para a App Store cobre o restante.

npm i @capacitor/core
npm i -D @capacitor/cli
npx cap init
npm i @capacitor/android @capacitor/ios
npx cap add android
npx cap add ios
npm run build && npx cap sync
npx cap open ios

Envie pela sua própria conta da Apple. A Diretriz 4.2.6 rejeita apps criados por um serviço de geração de apps, a menos que sejam "enviados diretamente pelo fornecedor do conteúdo do app." Nosso guia das diretrizes 4.3 e 4.2.6 explica como isso se aplica a apps feitos com IA.

Como evitar a rejeição pela Diretriz 4.2 com um app do Lovable empacotado?

Faça o app fazer coisas que o site não faz. A Diretriz 4.2 pede "recursos, conteúdo e UI que o elevem além de um site reempacotado", e a 4.2.2 exclui apps que sejam principalmente "recortes da web, agregadores de conteúdo ou uma coleção de links."

Use este checklist antes de enviar:

• O build web está incluído no binário e abre sem conexão de rede, mostrando dados em cache ou uma tela offline adequada.
• A navegação usa uma barra de abas inferior em vez de menu hambúrguer, e não há rodapés típicos de site nem banners de cookies.
• Login, cadastro e redefinição de senha acontecem dentro do app. Nada manda o usuário para o Safari.
• Pelo menos um fluxo principal depende do dispositivo, como captura pela câmera, notificações locais ligadas aos dados do próprio usuário, widgets ou biometria.
• Links externos para páginas de doação, lojas ou redes sociais foram removidos ou reduzidos ao mínimo.
• As notas para o App Review explicam por que o app é útil no celular e incluem um login de demonstração.

O que aconteceu quando outros apps baseados na web foram rejeitados pela 4.2?

Discussões públicas mostram o mesmo padrão: os revisores rejeitam UI com cara de web e links que abrem o Safari, e só adicionar pequenos recursos nativos não muda a decisão.

Em dezembro de 2020, um desenvolvedor no Ionic Forum teve um app de associação de clube rejeitado com "Seu app oferece uma experiência de usuário limitada, pois não é suficientemente diferente de uma experiência de navegação móvel", seguido de "a maior parte do conteúdo do app leva para o Safari." Remover o InAppBrowser e melhorar o suporte offline não foi suficiente, e o segundo envio também foi rejeitado. A terceira tentativa foi aprovada depois que o desenvolvedor reconstruiu a tela inicial com listas e cards de imagem em estilo nativo, adicionou mais notícias dentro do app e removeu a maioria dos links externos.

Em janeiro de 2026, um desenvolvedor nos Apple Developer Forums relatou que um app de agendamento foi rejeitado por "não ser suficientemente diferente de uma experiência de navegação na web", embora já usasse notificações push, Core Location e acesso aos contatos. A pessoa planejava adicionar haptics, ações rápidas e uma integração mais profunda com o calendário, e perguntou o que conta como "mais nativo". Até o momento em que este texto foi escrito, a discussão não tem respostas nem resultado confirmado.

A comparação: o primeiro desenvolvedor passou mudando o que o app é (conteúdo dentro do app, layouts nativos, sem links para fora). O segundo só adicionou APIs do dispositivo e continuava sem saber o que fazer. Concentre seu esforço na experiência principal, não em uma lista maior de permissões.

Quando reconstruir em vez de empacotar?

Reconstrua de forma nativa quando o valor principal do seu app for conteúdo web, ou quando você já tiver levado duas rejeições pela 4.2 com a mesma UI.

Exemplo prático: uma ferramenta de agendamento feita no Lovable para um estúdio de yoga mostra uma lista de aulas, um formulário de reserva e um link de checkout do Stripe. Empacotada como está, ela cai nos três sinais de alerta da 4.2: UI web, um link para fora e nenhum uso offline. Como PWA, ela pode ser lançada hoje sem custo extra. Para ter uma página na loja, mantenha o backend do Lovable, reconstrua a lista de aulas e o fluxo de reserva com telas nativas, adicione lembretes locais antes de cada aula e trate o pagamento dentro das regras da Diretriz 3.1 do App Review. Seu backend e seu modelo de dados continuam os mesmos. O que você reescreve é a UI.

Se quiser uma segunda opinião sobre qual caminho combina com seu projeto do Lovable, os serviços da The App Guy cobrem empacotamento, reconstrução e envio às lojas, ou mande um e-mail para yagyeshsrbobde@gmail.com.