Como Publicar App na Play Store e na App Store com IA [2026]

Publicar app na Play Store e na App Store é a etapa em que a maioria dos projetos feitos com IA empaca. O app roda bem no preview, o Claude Code ou o Cursor entregaram as telas em uma tarde, e de repente surge uma fila de exigências: conta de desenvolvedor, pacote assinado, política de privacidade, grupo de testadores, formulários de conformidade e uma revisão feita por pessoas. Cada etapa é simples isoladamente, e somadas consomem semanas de quem chega sem o roteiro.

Na Marfin, o Claude Code é a ferramenta que mais usamos para escrever e ajustar código, e o Cursor AI é a IDE do nosso building no dia a dia. As duas geram um projeto mobile inteiro, configuram o build e até redigem a política de privacidade. Abrir conta, pagar taxa, convocar testadores e responder aos revisores ficam com você, e a ordem em que você faz isso decide se o lançamento leva três semanas ou três meses.

Este guia segue a ordem em que as coisas precisam acontecer, porque o relógio de 14 dias de testes do Google deveria começar o quanto antes. Ele vale para quem criou o app com vibe coding, seja em Lovable, Cursor ou Claude Code, e quer colocar o resultado nas duas lojas. Passamos pelos caminhos técnicos, pelo passo a passo de cada loja, pelas políticas que mais derrubam apps gerados por IA, pelos custos e por nove dicas para evitar retrabalho.

Link para esta seçãoTrês caminhos para transformar um app feito com IA em app de loja

As lojas aceitam pacotes nativos: um arquivo AAB para o Google Play e um build assinado para a App Store. Se você só precisa colocar a versão web no ar, o nosso guia de deploy de app com IA resolve. Este aqui cobre o passo seguinte, e o primeiro movimento é descobrir de onde seu projeto vem, porque isso define o caminho.

Link para esta seçãoProjeto mobile desde o início com Expo

Se o app está no começo, o caminho mais curto é pedir ao Claude Code ou ao Cursor um projeto Expo com React Native. O Expo cuida de ícone, splash screen, permissões e assinatura, e o EAS Build compila na nuvem, o que dispensa um Mac para gerar o build de iOS. O EAS Submit envia o pacote direto para as duas lojas. É o fluxo que recomendamos para quem quer um app com cara de app, e combina bem com agentes: o agente edita TypeScript, roda o projeto, e você valida no celular com o Expo Go. Comparamos as IDEs e os agentes que servem para isso no guia das melhores IDEs com IA em 2026.

Link para esta seçãoSite responsivo embrulhado com Capacitor

Quem criou o app no Lovable, no V0 ou no Bolt.new tem uma aplicação web responsiva em React. O método mais usado para levá-la às lojas é o Capacitor, que coloca o site dentro de um contêiner nativo e dá acesso a câmera, notificações push, biometria e outros recursos do aparelho. O tutorial do Lovable mostra como exportar o projeto para o GitHub, e de lá o Claude Code adiciona o Capacitor, gera os projetos Android e iOS e prepara os builds. Projetos Next.js precisam de exportação estática para o Capacitor consumir, e as rotas de servidor passam para um backend à parte. O Bolt.new é outra opção e também gera projetos Expo, o que encurta o caminho para quem prefere ficar dentro da plataforma.

Esse caminho tem um risco que precisa ficar claro antes de começar. A Apple rejeita, pela diretriz 4.2 de funcionalidade mínima, apps que são apenas um site dentro de uma moldura. Para passar, o app precisa entregar algo que o navegador faz mal, como notificações push, login biométrico, modo offline ou integração com a câmera. O Google Play é mais tolerante com esse tipo de app, mas também derruba os que parecem incompletos.

Link para esta seçãoPWA empacotada para Android

Para quem quer apenas presença na Google Play, o PWABuilder e o Bubblewrap geram um pacote Android a partir de uma PWA usando Trusted Web Activity. É o caminho mais rápido para Android e segue as mesmas políticas da loja. Na Apple a opção equivalente esbarra na diretriz 4.2, e por isso tratamos a PWA como atalho só para o Android. Depois que o app existe como projeto nativo, o resto do roteiro vale para os três caminhos.

Link para esta seçãoComo publicar app na Play Store passo a passo

O Google Play tem o processo mais longo, por causa do teste obrigatório, e por isso começamos por ele.

Link para esta seçãoConta de desenvolvedor e verificação

Crie a conta no Google Play Console, com taxa única de US$ 25. O Google exige verificação de identidade: contas pessoais enviam documento oficial, e contas de organização precisam de número D-U-N-S e de um site da empresa. Para startups recomendamos a conta de organização, porque ela dispensa o teste fechado de 14 dias e deixa o app no nome da empresa. O número D-U-N-S é gratuito, mas a emissão pode levar de alguns dias a algumas semanas, então peça o quanto antes.

Link para esta seçãoTeste fechado com 12 testadores

Contas pessoais criadas depois de novembro de 2023 precisam rodar um teste fechado com pelo menos 12 testadores durante 14 dias seguidos antes de pedir acesso à produção. O Google reduziu o mínimo de 20 para 12 testadores em dezembro de 2024. Os testadores entram com o e-mail do Google e instalam pelo link do teste. Como alguém pode sair no meio do período, convide entre 15 e 20 pessoas para ter margem. Antes disso, use o teste interno, que aceita até 100 pessoas e libera o build em minutos, para validar o básico.

Link para esta seçãoBuild AAB, assinatura e target API

Apps novos aceitam apenas Android App Bundle (AAB), e o Play App Signing guarda a chave de distribuição. Com Expo, o comando eas build para Android gera o AAB e cuida da keystore. Com Capacitor, o Claude Code roda o Gradle e assina o bundle seguindo o projeto Android gerado. Guarde um backup da chave de upload em local seguro. Confira também o target API level: em agosto de 2025 o piso passou a ser o Android 15 (API 35), e o ciclo anual de agosto pede o nível seguinte, então veja no Play Console o valor vigente antes de buildar.

Link para esta seçãoFicha da loja e formulários de conformidade

Na ficha da loja, preencha o nome (até 30 caracteres), a descrição curta (até 80), a descrição completa (até 4.000), o ícone de 512 por 512 pixels, o gráfico de recursos de 1.024 por 500 e pelo menos duas capturas de tela. Depois vêm os formulários da seção de política do app: política de privacidade com URL pública, segurança dos dados, classificação de conteúdo, público-alvo, declaração de anúncios, acesso ao app e declarações sobre recursos financeiros e de saúde quando se aplicam. Se o app tem login, entregue ao revisor um usuário e uma senha de teste no campo de acesso ao app, ou a revisão trava. Apps com criação de conta também precisam oferecer a exclusão da conta dentro do app e um link web para o pedido de exclusão.

Link para esta seçãoProdução e revisão

Concluído o teste, peça acesso à produção, responda ao questionário do Google sobre o que aprendeu com os testadores e envie a versão. A primeira revisão de contas novas costuma levar de alguns dias até cerca de uma semana, e as seguintes saem em horas ou poucos dias. Use o lançamento em etapas, com 10% ou 20% dos usuários no início, para pegar falhas antes de chegar a todo mundo.

Vale acompanhar ainda a verificação de desenvolvedores do Android. O Google anunciou que ela começa em setembro de 2026 no Brasil, para apps instalados em aparelhos certificados. Quem publica pelo Play Console já passa pela verificação de identidade, e o aviso pesa mais para quem distribui APK por fora da loja.

Link para esta seçãoComo publicar app na App Store com TestFlight

A Apple tem menos etapas formais e uma revisão mais rigorosa de conteúdo e comportamento.

Link para esta seçãoConta Apple Developer

Matricule-se no Apple Developer Program por US$ 99 por ano. Contas individuais usam o Apple ID com autenticação em dois fatores e verificação de identidade. Contas de organização pedem o número D-U-N-S e a confirmação de que quem se cadastra tem autoridade para assinar pela empresa. A aprovação individual costuma sair em poucos dias, e a de organização pode demorar mais.

Link para esta seçãoBuild com Xcode 26 ou EAS

Desde abril de 2026, a Apple exige builds feitos com Xcode 26 e o SDK do iOS 26 para aceitar o upload no App Store Connect. Com Expo, o EAS Build resolve isso na nuvem e cuida de certificados e perfis de provisionamento, o que poupa quem não tem um Mac. Com Capacitor e outros projetos nativos, você abre o projeto no Xcode, escolhe o destino Any iOS Device, gera o archive e envia pelo Distribute App. Depois que a assinatura está configurada, o Claude Code consegue rodar o xcodebuild pelo terminal e repetir o processo a cada versão.

Link para esta seçãoApp Store Connect e TestFlight

No App Store Connect, crie o registro do app com bundle ID, nome, idioma principal e SKU. Suba o build e distribua pelo TestFlight: testadores internos (até 100) recebem o build em minutos, e testadores externos (até 10.000) passam por uma revisão beta antes. O TestFlight cumpre o papel do teste fechado do Google, sem contador de 14 dias, e vale usá-lo por pelo menos uma semana para pegar crashes em aparelhos diferentes.

Link para esta seçãoMetadados e revisão

A Apple pede capturas de tela do iPhone de 6,9 polegadas, descrição, palavras-chave de até 100 caracteres, URL de suporte, URL da política de privacidade, categoria, classificação etária e as etiquetas de privacidade do app. O questionário de classificação etária foi reformulado com as faixas 13+, 16+ e 18+, e vale responder com calma, porque a classificação afeta quem pode baixar o app. Informe um usuário de demonstração se houver login e escreva nas notas para o revisor o que o app faz e como testar. A revisão costuma levar de 24 a 48 horas.

Link para esta seçãoPolítica de privacidade, dados e IA: o que as duas lojas conferem

As duas lojas pedem uma política de privacidade em URL pública, e o texto precisa bater com o que o app faz. Peça ao Claude Code para listar os SDKs do projeto e os dados que cada um coleta, porque agentes adicionam analytics, anúncios e bibliotecas de login sem avisar, e tudo isso entra no formulário de segurança dos dados do Google e nas etiquetas de privacidade da Apple. No Brasil, a política deve citar a LGPD, indicar o controlador dos dados, o canal de contato e os direitos do titular.

Apps com IA ganharam regras próprias. Desde novembro de 2025, a diretriz 5.1.2(i) da Apple exige que o app informe quando dados pessoais vão para uma IA de terceiros e que o usuário dê permissão explícita antes. Se o seu app envia texto, foto ou voz para a API do Claude, da OpenAI ou do Gemini, mostre uma tela de consentimento antes do primeiro envio. O Google Play pede, para apps com IA generativa, um recurso dentro do app para o usuário denunciar conteúdo ofensivo gerado, e proíbe saídas que violem as políticas de conteúdo.

As duas lojas também exigem que apps com criação de conta ofereçam a exclusão da conta dentro do app. Se o app oferece login com Google ou outro serviço de terceiros, a Apple pede uma alternativa com privacidade equivalente, e a forma mais simples de cumprir a diretriz 4.8 é adicionar o Sign in with Apple. Para vender assinaturas ou itens digitais, use o sistema de compras da própria loja, que é o App Store In-App Purchase na Apple e o Google Play Billing no Android. Uma biblioteca como o RevenueCat reduz o trabalho de integrar os dois.

Link para esta seçãoOs motivos de rejeição mais comuns em apps feitos com IA

Os mesmos erros aparecem sempre nos apps gerados por agentes. O primeiro é conteúdo de rascunho: textos lorem ipsum, botões sem ação, telas com aviso de "em breve" e imagens de exemplo. A Apple rejeita sob a diretriz 2.1, de completude do app, e o Google também reprova por funcionalidade quebrada. O segundo é o crash na abertura do build de produção, quase sempre causado por variáveis de ambiente que existiam no desenvolvimento e sumiram na compilação. Teste o build de release em aparelho real antes de enviar.

O terceiro é o excesso de permissões. Agentes adicionam câmera, localização, microfone e armazenamento por precaução. No iOS, cada uso exige um texto explicando o motivo, como a chave NSCameraUsageDescription no Info.plist, e a ausência desse texto causa crash e rejeição. No Android, permissões sensíveis como acesso a fotos e vídeos, localização em segundo plano e SMS passam por declaração e análise do Google. Peça ao Claude Code para auditar o AndroidManifest e o Info.plist e remover tudo que o app não usa.

O quarto é a descrição que promete o que o app entrega pela metade. Textos de loja escritos por IA tendem ao exagero, e a diretriz 2.3 da Apple e a política de metadados do Google punem funções anunciadas que não existem. As capturas de tela precisam vir do app real, no formato certo para cada loja. O quinto é a falta de acesso para o revisor: sem usuário e senha de demonstração, o revisor fica preso na tela de login e devolve o app. O sexto é o site embrulhado sem recurso nativo, que já descrevemos na diretriz 4.2.

Link para esta seçãoComparativo: Google Play e App Store lado a lado

A tabela resume as diferenças que mais afetam o cronograma de um app feito com IA.

Item	Google Play	App Store
Taxa da conta	US$ 25, pagamento único	US$ 99 por ano
Formato do pacote	AAB	IPA, via Xcode ou EAS Build
Teste antes da produção	Teste fechado com 12 testadores por 14 dias (contas pessoais novas)	TestFlight, sem prazo mínimo
Tempo de revisão	De horas a cerca de 7 dias, mais lento em contas novas	24 a 48 horas na maioria dos casos
Precisa de Mac	Não	Só com Xcode, com EAS Build a nuvem resolve
Documentação de privacidade	Formulário de segurança dos dados	Etiquetas de privacidade
Exclusão de conta	Dentro do app e link web	Dentro do app

Na prática, o Google pede mais tempo no começo, por causa do teste de 14 dias, e a Apple pede mais rigor no conteúdo e no comportamento do app. Por isso a ordem que recomendamos é abrir as duas contas juntas, iniciar o teste fechado no Google, rodar o TestFlight em paralelo e enviar para revisão quando os dois testes terminarem.

Link para esta seçãoPreços e planos: quanto custa publicar app na Play Store e na App Store

O custo fixo para estar nas duas lojas no primeiro ano é de US$ 124, somando US$ 25 pagos uma única vez ao Google e US$ 99 por ano à Apple. A partir do segundo ano, só a anuidade da Apple se repete. As ferramentas de build entram à parte.

Item	Valor	Observação
Google Play Console	US$ 25, pagamento único	Verificação de identidade obrigatória
Apple Developer Program	US$ 99 por ano	Isenção para ONGs e instituições de ensino
Número D-U-N-S	Gratuito	Necessário nas contas de organização
Expo EAS Build	Plano gratuito com cota mensal de builds	Fila mais lenta no plano gratuito
Capacitor	Gratuito, código aberto	Builds locais usam Android Studio e Xcode
Supabase	Free, Pro a US$ 25 por mês	Team a US$ 599 por mês

Sobre a comissão em vendas dentro do app, o Google cobra 15% nos primeiros US$ 1 milhão de receita por ano e 30% acima disso, e as assinaturas pagam 15% desde o primeiro dia. A Apple cobra 15% de quem entra no Small Business Program, com receita abaixo de US$ 1 milhão por ano, e 30% nos demais casos. Apps gratuitos sem compras digitais não pagam comissão alguma. O Supabase Free costuma bastar para o lançamento, e o Pro entra quando o app ganha tráfego e precisa de backups diários.

Link para esta seção9 dicas para publicar app na Play Store e na App Store sem retrabalho

1. Abra as duas contas no primeiro dia. Verificação de identidade, número D-U-N-S e aprovação da Apple levam de dias a semanas, e esse tempo corre em paralelo ao desenvolvimento. Deixar para o fim cria uma espera que o código pronto não resolve.

2. Comece o teste fechado com a primeira versão instalável. Você pode enviar atualizações durante os 14 dias, então o app pode estar longe do ideal. Recrute testadores entre clientes, amigos e comunidade, e peça que mantenham o app instalado até o fim do período.

3. Peça uma auditoria de permissões ao agente. Com o Claude Code, mande ler o AndroidManifest e o Info.plist, listar cada permissão com a tela que a usa e remover o que sobrar. Menos permissões significam menos formulários e menos motivos de rejeição.

4. Mantenha chaves secretas fora do pacote. Qualquer app mobile pode ser descompilado, então as chaves de API de IA ficam em edge functions ou em um backend seu. No Supabase, ative o RLS em todas as tabelas e embarque apenas a chave anon, porque a service role dá acesso total ao banco.

5. Gere a política de privacidade a partir do código. Peça ao agente a lista de SDKs, dados coletados e serviços de terceiros, e use essa lista para redigir o texto com a LGPD e para preencher os formulários das lojas. Publique em uma URL estável e revise a política a cada nova integração.

6. Implemente a exclusão de conta antes de enviar. As duas lojas exigem o fluxo dentro do app, e o Google pede também um link web para o pedido. Agentes costumam esquecer essa tela, então inclua no prompt desde o começo.

7. Prepare conta de demonstração e notas para o revisor. Crie um usuário com dados de exemplo, informe as credenciais nos campos de acesso e escreva dois ou três parágrafos explicando o que o app faz e como testar cada função. Revisores com contexto aprovam mais rápido.

8. Teste o build de release em aparelhos reais. O modo de desenvolvimento esconde erros de variáveis de ambiente, minificação e assinatura. Instale o AAB pelo teste interno e o IPA pelo TestFlight antes de enviar para a revisão.

9. Use lançamento gradual e monitore os erros. No Google Play, libere primeiro para 10% ou 20% dos usuários, e na Apple use a liberação em fases das atualizações. Com Sentry ou Firebase Crashlytics instalados, você vê as falhas em horas e corrige antes que a nota da loja caia.

Publicar app na Play Store e na App Store dá um trabalho previsível. Com a ordem certa, que é contas primeiro, teste fechado cedo, build de release, políticas escritas a partir do código e revisão com notas claras, um app feito com IA chega às duas lojas em três a quatro semanas, e a maior parte desse tempo é espera pelo relógio do Google e pelas revisões. O código que o agente escreve é a parte rápida do projeto.

Se o app ainda está no papel, o guia de como criar app sem programar mostra o começo do caminho, e o roteiro acima leva o resultado até as duas lojas. Abra as contas hoje e comece o teste fechado assim que existir a primeira versão instalável.

Leia também:

TL;DR