Oito motivos pelos quais a revisão da App Store devolve seu app

A resposta curta: a maioria das rejeições de apps na App Store e no Google Play não é causada por um bug de código. Ela é causada por itens administrativos que o dono do negócio controla, não o desenvolvedor — uma conta de demonstração com a qual o revisor consiga fazer login, uma política de privacidade completa, uma declaração de dados que corresponda à realidade, uma conta de desenvolvedor no nome da empresa e um prazo técnico que já venceu. Tudo isso pode ser preparado duas semanas antes do lançamento sem escrever uma única linha de código.

O impacto no cronograma é maior do que parece. Uma rejeição não significa que o app é ruim; significa que o app volta para o fim da fila depois de cada correção, e assim uma campanha de lançamento ligada a uma data sazonal ou a um evento vira um atraso sem prazo definido. Por isso o dossiê de publicação merece ser tratado como parte do projeto, e não como papelada deixada para o último dia.

1 — Não há uma conta de demonstração para o revisor abrir seu app

Este é o motivo mais repetido em apps que começam com uma tela de login. O revisor não é um dos seus clientes e não tem um número de telefone cadastrado no seu sistema, então, sem credenciais prontas, ele para na primeira tela. A regra de completude do app da Apple (App Completeness, 2.1) é explícita: envie uma versão final, inclua as informações de uma conta de demonstração se o seu app tiver login e mantenha seu serviço de back-end ligado. Se obrigações legais ou de segurança impedirem você de fornecer uma conta real, é possível incluir um modo de demonstração embutido que mostre toda a funcionalidade do app, com aprovação prévia da Apple.

Na prática: prepare uma conta permanente que não expire e não seja apagada nas limpezas de dados, e garanta que os servidores de staging estejam funcionando durante a janela de revisão, não apenas no seu horário comercial.

2 — A loja enxerga seu app como um site reempacotado

A regra de funcionalidade mínima (Minimum Functionality, 4.2) determina que um app deve incluir recursos, conteúdo e interface que o elevem acima de um site reempacotado, e que apps que são principalmente material de marketing, recortes da web, agregadores de conteúdo ou uma coleção de links não são aceitos. Muitas empresas pedem um app porque o concorrente tem um, e o produto sai como uma cópia do site dentro de uma casca.

Há duas saídas: ou você dá ao app um valor real que o navegador não consegue entregar — uso offline, notificações conforme o status do pedido, leitura de código de barras, dados armazenados no aparelho, integração com pagamentos e mapas — ou publica um aplicativo web progressivo em vez de passar pelas lojas. Tratamos dessa escolha em aplicativo web progressivo ou app nativo.

3 — A política de privacidade está incompleta ou ausente dentro do app

A regra de coleta de dados da Apple (Data Collection, 5.1.1) exige um link para a política de privacidade nos metadados do App Store Connect e dentro do app, em um local de fácil acesso. A política deve identificar quais dados são coletados, como e todos os seus usos; confirmar que qualquer terceiro com quem você compartilha dados — ferramentas de analytics, redes de anúncios, SDKs de terceiros — oferece a mesma proteção; e explicar as políticas de retenção e exclusão e como o usuário revoga o consentimento.

Não é uma página que você copia de outro site. É uma descrição do que o seu sistema realmente faz, e ela precisa estar alinhada às suas obrigações perante a Lei de Proteção de Dados Pessoais da Arábia Saudita (PDPL), como explicamos no nosso guia prático da PDPL.

4 — Não há exclusão de conta dentro do app

A regra 5.1.1 (v) é clara: se o seu app permite criar conta, você também deve oferecer a exclusão da conta dentro do app. E ela acrescenta uma regra que muitas equipes deixam passar: se o seu app não tem recursos significativos baseados em conta, deixe as pessoas usarem sem login, e não exija informações pessoais a menos que sejam diretamente relevantes para a funcionalidade principal ou exigidas por lei.

A exclusão de conta aqui não é só um botão na interface; é um fluxo completo no back-end. O que acontece com os pedidos, as notas fiscais e os registros contábeis do cliente que, por lei, não podem ser apagados? A resposta usual é separar os dados de identidade dos registros financeiros antes de o desenvolvimento começar, e não depois.

5 — A declaração de segurança dos dados do Google Play não corresponde ao que o app faz

O Google exige que todo desenvolvedor declare os dados que o app coleta e transmite para fora do aparelho, incluindo os dados coletados por bibliotecas e SDKs de terceiros, se a coleta é obrigatória ou opcional, a finalidade, se os dados são criptografados em trânsito e se existe um mecanismo de solicitação de exclusão. A política diz que somente o desenvolvedor é responsável pela precisão das declarações, e que violações levam ao bloqueio de atualizações ou à remoção do Google Play.

O erro comum é simples: um desenvolvedor adicionou uma ferramenta de analytics ou de relatório de falhas para facilitar o próprio trabalho, e ninguém a colocou na declaração. Faça uma única pergunta à sua equipe antes de enviar: qual é a lista completa de pacotes de terceiros deste app, e o que cada um deles envia?

6 — A atualização é rejeitada porque o app tem como alvo uma versão antiga do Android

Desde 31 de agosto de 2026, o Google Play exige que apps novos e atualizações tenham como alvo o Android 16 (nível de API 36) ou superior, com exceções: Wear OS e Android Automotive no nível 35, e Android TV e Android XR no nível 34. Os desenvolvedores que pediram prorrogação têm até 1º de novembro de 2026.

A consequência operacional para o dono do negócio: o seu app publicado continua na loja, mas você não consegue lançar nenhuma atualização — nem mesmo uma correção de segurança urgente ou uma mudança de preço — até que ele seja recompilado no nível exigido. Todo app que não é atualizado há um ano merece uma verificação desse ponto antes que você precise de uma versão urgente.

7 — Contas novas precisam de 12 testadores e 14 dias antes de publicar

Contas pessoais de desenvolvedor criadas no Google Play depois de 13 de novembro de 2023 não podem publicar para o público logo de cara. Elas precisam de um teste fechado com no mínimo 12 testadores inscritos continuamente por pelo menos 14 dias antes de pedir acesso à produção. São duas semanas a mais no cronograma e 12 pessoas reais com contas Google reais.

Do outro lado, inscrever-se no Apple Developer Program como organização exige um número D-U-N-S e uma pessoa jurídica capaz de firmar contratos, sob a razão social da organização — não um nome fantasia nem uma filial. Obter o número e passar pela verificação leva dias. Comece isso na primeira semana do projeto, não na semana do lançamento.

8 — Metadados da loja, capturas de tela e um app separado por filial

Três regras pequenas derrubam lançamentos inteiros: as capturas de tela devem mostrar o app em uso, não a arte do título, a página de login ou a tela de abertura (2.3.3); o nome do app é limitado a 30 caracteres e os metadados não podem ser recheados com termos de marcas registradas, nomes de apps populares ou preços (2.3.7); e você não pode criar vários bundle IDs do mesmo app (4.3a) — que é exatamente o que acontece quando uma empresa pede um app separado por filial ou por cidade. O padrão correto é um único app em que o usuário seleciona a filial.

Como esse portão se encaixa no plano do projeto

  • Registre a conta de desenvolvedor no nome da sua empresa, não no do desenvolvedor ou da agência. Ela é um ativo da empresa, como o domínio, conforme explicamos em quem é dono dos direitos do seu software.
  • Abra as contas na primeira semana: a Apple cobra US$ 99 por ano e o Google Play cobra uma taxa única de US$ 25, e o que leva tempo é a verificação, não o pagamento.
  • Coloque uma cláusula no contrato definindo quem envia o build e responde às observações da revisão, e quantos ciclos de revisão o preço cobre.
  • Trate o dossiê de publicação como uma entrega própria: política de privacidade, declaração de dados, capturas de tela, descrição, conta de demonstração e a lista de pacotes de terceiros.
O código fica pronto uma semana antes do lançamento. O dossiê de publicação precisa de duas semanas. Errar essa ordem está por trás da maioria dos lançamentos atrasados.

Fontes