Publicar seu app na App Store e no Google Play

O que é seu e o que é nosso

O app sai sob a sua conta de desenvolvedor, nunca sob a nossa. Isso não é detalhe burocrático: a ficha da loja, as avaliações, os downloads e o dinheiro das compras são seus, e continuam seus se um dia você sair da plataforma.

O que fazemos: empacotamos o app publicado numa casca nativa, geramos o ícone e a tela de abertura, compilamos na nuvem (não precisa de Mac) e enviamos para a loja com a credencial que você conectou. O que é seu: a conta de desenvolvedor, criar o app no console da loja e responder à revisão.

O app nativo roda a versão publicada do seu projeto. Se você ainda não publicou na web, a aba pede isso antes, porque não há o que empacotar.

Antes de começar

• o projeto publicado na web (aba Publicar);
• plano Builder ou superior;
• conta de desenvolvedor na loja onde você quer sair: Google Play (taxa única de US$ 25) e/ou Apple Developer Program (US$ 99 por ano), pagos direto à loja;
• uma hora de paciência com o console da loja na primeira vez.

Dá para fazer só Android agora e iOS depois. As duas plataformas andam separadas do começo ao fim.

Onde fica

Na aba Aplicativo, na coluna de ícones do editor. É a última da lista, com o ícone de celular.

Os cinco passos da configuração

O assistente salva sozinho a cada passo, então dá para sair no meio e voltar depois.

Marca

O ícone precisa ser um PNG quadrado de 1024×1024. Sem ele, geramos um com a inicial do app sobre a cor da sua marca. A Apple recusa ícone com fundo transparente: envie com o fundo preenchido e sem cantos arredondados, que o sistema arredonda sozinho.

A tela de abertura funciona melhor como um PNG com a marca ao centro e fundo transparente, porque a cor que você escolher preenche o resto da tela. Uma foto de tela inteira fica cortada de um jeito diferente em cada aparelho.

O identificador do app

É o endereço único do app nas lojas, no formato com.suaempresa.seuapp. Sugerimos um a partir do nome do projeto, e você pode trocar por um do seu domínio ao contrário.

Ele não muda depois da primeira publicação. Trocar depois não renomeia o app: cria um app novo na loja, e a base de usuários, as avaliações e os downloads ficam no antigo. Confira antes de publicar.

No Google Play há uma armadilha a mais: o app precisa existir no console com exatamente esse identificador antes do envio. A API do Google não cria o app, então, se o pacote não existir lá, o envio falha com Package not found. A tela mostra o identificador com um botão de copiar justamente para você colar no Play Console sem errar um caractere.

Recursos

Ative o que o app realmente usa. As lojas cobram que um app nativo use recursos nativos de verdade: um app que é só o site dentro de uma casca costuma ser recusado, com mais frequência pela Apple.

Ativar push aqui é o que faz o app pedir permissão de notificação. No Android, entregar a notificação ainda exige os dois arquivos do Firebase, que ficam no passo Contas.

Build de teste: instale antes de enviar

Antes de mandar para a loja, use o Build de teste. Ele gera um app instalável direto no aparelho, sem passar pela loja, e leva de 10 a 30 minutos.

Os dois lados se comportam de forma diferente quando o build termina:

• Android: sai um APK e o botão Instalar entrega o arquivo. Instala no aparelho na hora;
• iOS: o pacote é enviado ao App Store Connect e aparece no TestFlight depois que a Apple processa. Não há arquivo para baixar e instalar no iPhone direto.

Vale sempre: um app que você nunca abriu no aparelho não deveria ir para revisão.

Publicar

No passo Revisar, o botão é Publicar nas lojas. A partir daí a tela mostra três estados, por plataforma:

A diferença entre os dois últimos é a que mais confunde, e é real: um pacote pode ficar pronto e ainda assim ser recusado no envio (identificador errado, permissão faltando). Por isso "Enviado à loja" só aparece quando a loja confirma o recebimento, e não quando o build termina.

Depois disso, quem informa é o console da loja. A revisão acontece dentro da Apple e do Google, e não temos como acompanhá-la. Leva de algumas horas a 2 dias, com casos mais longos quando é a primeira versão do app.

Conta pessoal nova no Google Play: os 12 testadores

Se a sua conta do Google Play é pessoal e foi criada depois de 13 de novembro de 2023, o Google exige, antes de liberar a produção, um teste fechado com no mínimo 12 testadores inscritos continuamente por 14 dias. É por app, não por conta.

Isso não é um requisito da Fabapp e não tem como contornar por aqui: o envio funciona, o app fica disponível na faixa de teste, e a produção só abre depois de você pedir acesso e o Google aprovar (leva até 7 dias). Contas de organização e contas pessoais criadas antes daquela data estão fora da exigência.

Planeje isso desde o começo se você tem conta nova: são 14 dias de calendário que não dá para acelerar.

Os prazos das lojas que são nossos, não seus

As lojas exigem que o app seja compilado com versões recentes das ferramentas, e esses prazos são responsabilidade nossa: mantemos a casca nativa atualizada e você não precisa fazer nada.

Para você saber que existem: o Google Play exige que apps novos e atualizações passem a mirar o Android 16 (API 36) a partir de 31 de agosto de 2026, e a Apple exige que envios ao App Store Connect sejam compilados com o SDK do iOS 26 ou superior a partir de 28 de abril de 2026.

Quando algo falha

O log completo de cada build fica na própria aba, no link Ver o log completo. Ele é a primeira coisa a olhar, e a mensagem de erro dele costuma ser literal.