Quanto custa publicar um app na App Store e no Google Play?
Um guia direto sobre o custo de publicar um app e o trabalho que existe antes do botão de envio.
O custo para publicar um app não é apenas o upload da build. Ele muda conforme contas de desenvolvedor, estabilidade, capturas, ficha da loja, privacidade, acessos de teste, pagamentos, analytics e risco de rejeição. As taxas oficiais das plataformas são pagas separadamente e não substituem a preparação de lançamento.
Estime a aplicação com um breve questionário
ComeçarO que as taxas oficiais cobrem
As taxas oficiais servem para acessar as plataformas. Apple cobra uma assinatura anual do programa de desenvolvedores, enquanto Google Play cobra um registro único na Console. Isso permite distribuir o app, mas não cria capturas, não testa pagamentos, não revisa privacidade, não prepara conta demo e não corrige rejeição.
Por isso, o orçamento precisa dizer o que está incluído. Um upload simples de arquivos prontos é diferente de um suporte de lançamento com revisão da build, preparação da ficha, trilhas de teste, comunicação com review e reenvio quando algo precisa ser corrigido.
O que um serviço de publicação deve incluir
Em um MVP simples, o pacote costuma incluir conta de desenvolvedor, identificador do app, ícone, capturas, nome, descrição, categoria, classificação etária, link de suporte, link de privacidade, notas da versão e instruções para o revisor. Sem isso, a app pode parecer incompleta.
Em um produto comercial, entram TestFlight ou testes do Google Play, verificação de crashes, eventos de analytics, notificações, assinaturas, pagamentos, dados de exemplo e backend de produção. Se o app tem reservas, cursos, pedidos, chat privado, marketplace ou admin-panel, o revisor precisa conseguir passar pelo fluxo principal.
Por que o custo varia
O maior fator é maturidade. Uma build estável, com fluxo principal claro, é mais barata de publicar. Um app com backend em homologação, login frágil, capturas antigas, textos exagerados ou privacidade mal preenchida exige mais cuidado e aumenta a chance de rejeição.
| Fator | O que revisar | Por que muda o custo |
|---|---|---|
| Contas | proprietário, empresa, permissões, papéis | sem dono claro o lançamento trava |
| Página da loja | título, descrição, capturas, categoria | afeta revisão e conversão |
| Privacidade | dados, SDKs, analytics, suporte | precisa bater com o app real |
| Acesso demo | usuário, dados, papéis, ambiente | o revisor precisa testar o fluxo principal |
| Pagamentos | assinaturas, serviços, compras, reembolsos | regras mudam por modelo de negócio |
| Rejeição | notas, correções, nova build | um retorno pode adicionar outro ciclo |
Quando publicar por conta própria
Faz sentido publicar internamente quando o app é simples, as contas já pertencem à empresa, a build passou por QA, não há cenários sensíveis e alguém do time consegue responder rápido à loja. Nessa situação, uma revisão final pode bastar.
O risco aparece quando quem envia o app não entende o produto. O revisor pode precisar de um pedido de exemplo, uma reserva, uma rota de entregador, uma conta premium, uma aula cadastrada ou acesso de administrador. Sem esse contexto, um app funcional pode parecer vazio.
Tem uma ideia de app e quer entender o próximo passo?
Revisar minha ideiaQuando contratar suporte de lançamento
Suporte vale a pena quando o lançamento está ligado a vendas, campanha, parceiros, investidores, franquias ou contrato com cliente. Também é útil em apps com assinaturas, pagamentos, marketplace, localização, dados privados, saúde, moderação ou integrações com CRM e ERP.
Na Appfyl, tratamos publicação como parte do lançamento, não como tarefa solta. Se desenvolvemos o app, a primeira versão pública precisa combinar com o escopo, o plano de testes e a página da loja. Se avaliamos um app feito por outro time, primeiro revisamos build, contas, privacidade, analytics e materiais.
O que preparar antes do orçamento
Separe estado da build, plataformas, dono das contas, política de privacidade, link de suporte, capturas, textos da loja, acesso demo e descrição curta do fluxo principal. Se houver pagamento, explique se vende conteúdo digital, produto físico, serviço, reserva ou transação entre usuários.
Também defina países e idiomas do primeiro lançamento. Localizar a ficha pode ser uma adaptação pequena ou um trabalho maior com capturas locais, moeda, pagamentos, confiança, suporte e textos legais. Quanto antes isso for decidido, menor o retrabalho.
Vale incluir uma lista do que ainda não está pronto. Muitas equipes deixam isso para depois, mas esse detalhe muda bastante o orçamento. Se as capturas são provisórias, se a política de privacidade ainda não foi revisada, se produtos de assinatura não existem ou se o backend ainda está em ambiente de teste, o plano de publicação precisa tratar isso como risco real.
Se o app já foi rejeitado, envie a mensagem completa da loja, a build analisada, os acessos usados pelo revisor e o que foi alterado desde então. Com esse contexto, fica mais fácil decidir se basta ajustar a ficha e escrever uma nota melhor ou se a solução exige uma nova build.
Trabalho oculto que costuma surgir
Os atrasos normalmente vêm de incoerências. A ficha promete uma função que não está na build. As capturas mostram uma tela antiga. O formulário de privacidade esquece um SDK. O login bloqueia o revisor. A assinatura funciona no teste, mas falha em produção. O suporte abre uma página vazia.
Depois da aprovação ainda existe lançamento. É preciso acompanhar crashes, eventos, pagamentos, avaliações e mensagens de suporte. A publicação só está completa quando os primeiros usuários conseguem terminar o fluxo principal sem ajuda manual.
Também é importante definir manutenção do canal de publicação. Quem pode enviar nova versão? Quem atualiza capturas e notas de release? Quem responde avaliações? Quem verifica se uma nova versão do sistema operacional afetou login, push ou pagamento? Essas responsabilidades pequenas evitam que a app fique publicada, mas difícil de operar.
Transforme pesquisa em plano
A Appfyl transforma sua ideia em um plano claro do app, uma lista de funções e o primeiro plano de trabalho.
Discutir o plano do appPontos principais
- Taxas oficiais das lojas são separadas do trabalho de lançamento.
- O custo depende mais da prontidão do app do que do upload.
- Privacidade, acesso demo e pagamentos causam muitos atrasos evitáveis.
- Um bom orçamento define assets, QA, resposta à review e reenvio.
- Para apps de negócio, publicação, analytics e suporte devem andar juntos.
Links úteis
Perguntas frequentes
Não. Publicação cuida do lançamento nas lojas. Se a revisão mostra falhas de login, pagamento, privacidade ou estabilidade, isso vira trabalho de produto.
Para uma empresa, o ideal é publicar pela conta da própria empresa. Isso protege atualizações, pagamentos, analytics, suporte e controle futuro.
O envio pode ser rápido, mas o primeiro lançamento depende de verificação da conta, testes, revisão, rejeições e velocidade de resposta do time. Planeje dias ou semanas.
Instale o app do zero, teste o fluxo principal, confira acessos demo, capturas, privacidade, pagamentos e servidor. Assim o orçamento fica muito mais preciso.