Como os apps sao aprovados na App Store e no Google Play
A revisao recusa todos os dias cascas web vazias, links quebrados e falhas de privacidade. Veja por que apps sao recusados, o que os revisores checam e como passar nas duas lojas.
Por que a revisao existe (e o que ela testa de verdade)
Antes de chegar a um unico usuario, seu app passa pela revisao da Apple e do Google. A revisao nao existe para complicar sua vida: ela protege as pessoas de apps inseguros, quebrados, enganosos ou simplesmente vazios. Para ter seu app aprovado na App Store e no Google Play, voce precisa cumprir dois conjuntos de regras distintos: as App Review Guidelines da Apple e as Politicas do Programa para Desenvolvedores do Google Play.
As duas lojas coincidem no essencial — seguranca, privacidade, metadados honestos e funcionalidade real — mas diferem no tom e no processo. A revisao da Apple e mais rigorosa e em grande parte manual: uma pessoa abre seu app e o usa. O Google se apoia mais na analise automatica, com revisores humanos para casos limite. No fundo, ambas perguntam a mesma coisa: 'isto e um produto real, seguro e util?'. Quando voce internaliza isso, para de adivinhar e passa a projetar pensando na aprovacao.
Os motivos de recusa mais comuns
O grande vilao e a casca web vazia. A diretriz 4.2 da Apple (Funcionalidade minima) diz de forma explicita que um app deve oferecer recursos, conteudo e interface que vao alem de um site reempacotado, e o Google Play penaliza apps que sao apenas um invólucro de um site movel sem valor agregado. Se o seu app e um navegador apontado para a sua URL, conte com a recusa.
Os demais motivos sao praticos: links quebrados ou telas sem saida, travamentos e bugs durante a revisao, uma politica de privacidade ausente ou inacessivel, declaracoes de privacidade incompletas (os rotulos da Apple, o formulario de Seguranca dos dados do Google), rastrear usuarios sem o aviso App Tracking Transparency da Apple, capturas ou metadados enganosos e barreiras de login sem credenciais de teste para o revisor. Todos sao evitaveis e documentados: sao motivos recorrentes para um envio voltar.
O que os revisores da App Store e do Google Play realmente procuram
Os revisores seguem uma lista mental curta. Primeiro: o app faz algo nativo e util, ou e uma pagina que voce poderia abrir no Safari ou no Chrome? Segundo: e estavel — sem travamentos, sem telas em branco, sem fluxos claramente quebrados? Terceiro: e honesto — as capturas, a descricao e a categoria correspondem ao que o app realmente faz?
Depois vêm privacidade e permissoes. Se o app pede camera, localizacao ou notificacoes, o revisor espera um motivo claro e em contexto, alem de uma declaracao de privacidade coerente. Se ele gerencia contas, o revisor precisa entrar — por isso um login de teste que funcione (ou um modo convidado) e inegociavel. Por fim, checam a classificacao de conteudo, as opcoes de login e as regras proprias de cada plataforma. Nada e segredo — esta tudo nos guias — mas e preciso cumprir de verdade, nao apenas declarar.
Por que um app nativo de verdade passa na revisao (e uma casca fina, muitas vezes, nao)
O caminho mais confiavel para superar a Funcionalidade minima e oferecer a loja comportamento nativo real. Um app nativo de verdade — uma casca Swift no iOS, uma casca Kotlin no Android — que carrega seu site ao vivo dentro de um contêiner nativo de alto desempenho e adiciona recursos do aparelho por meio de uma ponte JavaScript e um produto de outra categoria em relacao a um simples invólucro. Notificacoes push, modo offline, login biometrico, deep links, camera, widgets na tela inicial e atalhos de app sao exatamente o 'valor nativo' que se pede aos revisores para procurar.
Essa e a abordagem da Transform To APP. O conteudo publicado no seu site continua aparecendo na hora no app — sem reenvio por um artigo ou uma mudanca de preco — enquanto a casca nativa fornece a funcionalidade que satisfaz as duas lojas. Voce obtem as atualizacoes rapidas da web e a profundidade nativa que passa na revisao, sem precisar escolher.
Sua checklist antes de enviar nas duas lojas
Revise-a antes de clicar em 'Enviar'. Ela evita a maioria das recusas evitaveis:
- Valor nativo: pelo menos um ou dois recursos reais do aparelho (push, offline, biometria, camera, widgets), nao apenas uma URL carregada. - Estabilidade: teste em um aparelho real; sem travamentos, sem telas em branco, com cada link e botao funcionando. - Politica de privacidade: URL ativa e acessivel, vinculada no app e na ficha da loja. - Declaracoes: rotulos de privacidade da Apple e formulario de Seguranca dos dados do Google preenchidos com exatidao; aviso ATT se voce rastreia. - Permissoes: peca apenas o que usa, cada uma com uma explicacao clara e em contexto. - Acesso: conta de teste operante ou modo convidado para o revisor, se houver login. - Metadados: capturas e descricao condizentes com o app real; categoria e classificacao corretas.
Marque todas as caixas e voce elimina quase todos os motivos que um revisor teria para recusar.
Publicar com suas proprias contas de desenvolvedor
A aprovacao tambem depende de onde o app vive. As duas lojas exigem contas de desenvolvedor: o Apple Developer Program custa 99 USD por ano e a conta de desenvolvedor do Google Play tem pagamento unico de 25 USD. Publicar com suas proprias contas faz o app levar a sua marca, o seu icone e o nome da sua empresa, sem rastros de terceiros na ficha.
A Transform To APP compila e envia com as contas Apple e Google do proprio cliente, e nao sob uma identidade de publicador compartilhada, entao a ficha e inteiramente sua e voce controla as atualizacoes futuras. Como o conteudo flui do seu site ao vivo, apenas as mudancas nativas exigem uma nova compilacao e um novo envio — e disso cuidamos nos. O resultado e um app nativo de verdade que passa na revisao, que voce possui por completo e que se mantem atualizado sem passar pela fila de revisao a cada palavra que voce muda no site.
FAQ
Quanto tempo leva a revisao de um app?+
Varia. A Apple costuma revisar em um ou dois dias, enquanto o Google pode ir de algumas horas a varios dias, e ambas podem demorar mais em um primeiro envio, diante de um problema sinalizado ou em periodos de alta demanda. Envie com folga antes de qualquer data de lancamento e nunca prometa uma estreia publica que dependa de aprovacao no mesmo dia.
Um app feito a partir do meu site sera recusado?+
Uma casca fina que apenas carrega seu site sem funcionalidade adicional e um motivo comum de recusa pela regra de Funcionalidade minima da Apple e pela politica equivalente do Google. Um app nativo de verdade que carrega seu site ao vivo dentro de uma casca nativa e adiciona recursos reais do aparelho (push, offline, biometria, widgets) e justamente o que os revisores procuram, e por isso passa.
Preciso das minhas proprias contas de desenvolvedor Apple e Google?+
Sim. O Apple Developer Program custa 99 USD por ano e a conta do Google Play tem pagamento unico de 25 USD. Publicar com suas proprias contas mantem o app sob a sua marca e lhe da a propriedade total da ficha e das atualizacoes futuras.
O que acontece se meu app for recusado?+
Voce recebe o motivo especifico e a diretriz relacionada. Na maioria dos casos, voce corrige o problema e reenvia; muitas recusas se resolvem rapido quando a causa fica clara. Se voce acredita que a recusa e um erro, as duas lojas oferecem um processo de recurso ou resolucao.
Se eu atualizar meu site, preciso reenviar o app?+
Nao. Com um app nativo que carrega seu site ao vivo, mudancas de conteudo — novos artigos, produtos ou precos — aparecem na hora no app, sem reenvio. Apenas mudancas nativas, como um novo recurso do aparelho, exigem recompilacao e nova revisao.