Rejeição na App Store: como corrigir, diretriz por diretriz (2026)

Uma rejeição na App Store é uma mensagem do App Review que cita uma diretriz, descreve o que o revisor viu e segura o lançamento até que você corrija, explique ou recorra. Comece transformando essa mensagem em um problema que você consiga testar. O próximo passo depende de o revisor não ter conseguido usar o app, ter encontrado uma divergência de política ou precisar de mais informações. Em outubro de 2026, as App Review Guidelines tinham sido atualizadas pela última vez em 16 de outubro de 2026, então confira a numeração atual antes de citar uma seção.

O que a mensagem de rejeição da App Store realmente diz?

A mensagem de rejeição da App Store indica a diretriz aplicada pelo revisor, descreve o comportamento específico observado e lista os próximos passos. Muitas vezes inclui o dispositivo, a versão do iOS e capturas de tela.

Guarde a mensagem completa, as capturas de tela, o número do build e os detalhes do dispositivo. Leia a seção citada na página atual das diretrizes. Depois escreva uma frase: "O revisor não conseguiu concluir X porque Y." Se a mensagem pede informações em vez de relatar um defeito, anote exatamente o que está faltando. O texto padrão da Apple para a 2.1 também explica como reproduzir o problema: "Para apps novos, desinstale todas as versões anteriores do app de um dispositivo, depois instale e siga os passos para reproduzir o problema."

• A mensagem cita um crash, uma tela inacessível ou um recurso incompleto? Reproduza esse fluxo no build de release enviado, no tipo de dispositivo indicado pela Apple.
• Ela cita capturas de tela, a descrição ou as notas de revisão? Verifique se dá para corrigir só nos metadados.
• Ela cita pagamentos, login, privacidade ou funcionalidade mínima? Compare o comportamento do produto com a diretriz citada.

Quais diretrizes as rejeições da App Store citam e o que elas exigem?

Cada diretriz define um requisito concreto, então associe o número citado ao texto correspondente e teste com base nele. A tabela cita o texto atual das diretrizes mais mencionadas em mensagens de rejeição.

A atualização de 16 de outubro de 2026 adicionou a 2.5.19 para recursos ocultos, inativos ou não documentados, que antes eram cobertos pela 2.3.1. Ela também adicionou a 2.3.14 sobre ativos criativos e incorporou o entitlement Music Streaming Services ao entitlement StoreKit External Purchase Link na 3.1.1(a). Use a tabela como ponto de partida, não como correção garantida. Uma mesma diretriz pode cobrir problemas diferentes, e o exemplo do revisor é o caso concreto que você precisa resolver.

Como corrigir uma rejeição 4.2 por funcionalidade mínima?

Corrija uma rejeição 4.2 adicionando valor real ao app, não reescrevendo a descrição. A diretriz 4.2 diz: "Se o seu app não for particularmente útil, único ou 'com cara de app', ele não pertence à App Store."

Pergunte-se o que alguém consegue fazer no seu app que o torna útil como app. A pessoa pode concluir um fluxo, salvar um estado relevante, usar recursos do dispositivo de forma coerente com o app ou ter uma experiência mobile pensada para o aparelho. Nenhuma lista pública de recursos garante aprovação. Se esses fluxos já existem, liste-os nas notas de revisão com passos exatos e capturas de tela. Se o app basicamente exibe uma página web, ele precisa de trabalho de produto. Adicionar notificações ou uma tela de configurações vazia só para parecer nativo não substitui valor real para os usuários.

Como responder ao App Review no App Store Connect?

Responda no App Store Connect: abra o envio pelo link de problemas não resolvidos do app, clique em Resolve e depois em Reply to App Review. Segundo a página de ajuda da Apple, isso exige a função Account Holder, Admin ou App Manager.

1. Em Apps, selecione o app.
2. No topo da página, clique no link que indica que há problemas não resolvidos.
3. Na seção In Progress, clique em Resolve ao lado do envio.
4. Clique em Reply to App Review e digite seu texto.
5. Para incluir capturas de tela ou documentos, clique em Attach File e depois em Reply.

A Apple diz que você pode trocar mensagens e anexar arquivos "até reenviar para o App Review", então mande suas evidências antes de reenviar. Mantenha a resposta curta e objetiva: diga o que mudou, onde está e como verificar. Não argumente sobre outros apps que parecem fazer a mesma coisa.

Corrigir metadados, enviar um novo build ou recorrer?

Corrija os metadados e reenvie o mesmo build quando apenas as informações da ficha estavam erradas. Envie um novo build quando o comportamento do app precisa mudar. Recorra apenas quando você acredita que o app já cumpre a diretriz.

As orientações da Apple sobre recursos pedem que você "explique ponto a ponto como o seu app cumpre" a diretriz. Elas também dizem para não recorrer depois de já ter corrigido os problemas e reenviado. Um recurso completo "não garante" que a decisão será revertida. Para apps já publicados, a política Bug Fix Submissions das diretrizes diz que correções de bugs não serão atrasadas por violações de diretrizes, "exceto aquelas relacionadas a questões legais ou de segurança".

Como outros desenvolvedores resolveram rejeições reais na App Store?

Em tópicos públicos de fóruns, muitas rejeições 2.1 vieram de diferenças entre o ambiente do revisor e o do desenvolvedor: outra rede, outro dispositivo ou outro estado de permissões. Uma rejeição 4.2 é um problema de produto, então pequenos ajustes raramente resolvem.

Erro de login na 2.1. Um desenvolvedor nos Apple Developer Forums citou a mensagem "Especificamente, não conseguimos fazer login devido a um erro", embora as versões publicada e do TestFlight fizessem login com as mesmas credenciais. Outros desenvolvedores no tópico relataram correções diferentes. Um resolveu "trocando http por https no servidor web". Outro, após três rejeições, adicionou um estado "Verifique sua conexão" no lugar de um carregamento infinito. Um terceiro removeu o iPad do deployment target após cinco rejeições, o que contorna o problema abandonando o suporte ao iPad.

Crash na inicialização. No fórum do Solar2D, um desenvolvedor recebeu a mensagem "Não conseguimos revisar o app porque ele travou na inicialização" em um iPhone 13 mini com iOS 18.3.2. O log de crash anexado mostrava a ausência da chave NSUserTrackingUsageDescription. O desenvolvedor confirmou: "Passou depois de adicionar: NSUserTrackingUsageDescription."

App WebView na 4.2. Um desenvolvedor nos Apple Developer Forums relatou a 10ª rejeição de um app baseado em WebView. O revisor havia enviado uma captura de tela do menu lateral dizendo que faltava conteúdo. As telas principais já eram nativas, mas duas ou três ainda abriam uma WebView. A resposta marcada como solução veio do App Review e recomendava uma consultoria individual com o App Review. O tópico não confirma uma aprovação.

A comparação: os casos 2.1 foram resolvidos reproduzindo as condições do revisor e lendo o log de crash. O caso 4.2 empacou porque cada reenvio mudava só uma parte de um app que continuava sendo, em grande parte, um site.

Como evitar que a mesma rejeição aconteça de novo?

Transforme cada problema resolvido em um item do checklist de release e teste-o novamente no build de release antes de cada envio. As diretrizes da Apple avisam que a revisão "vai demorar mais" se um app for rejeitado repetidamente pela mesma violação.

• Apague o app e instale o build de release do zero em um iPhone e um iPad físicos.
• Faça login com a conta de revisão em uma rede sem servidores de desenvolvimento nem exceções de HTTP.
• Abra cada solicitação de permissão e confirme que todas as descrições de uso do Info.plist existem.
• Garanta que cada compra no app foi enviada, está visível e explicada nas notas de revisão.
• Atualize as notas de revisão sempre que um fluxo mudar. Não cole notas de seis versões atrás.

Para problemas 2.1, siga o plano de testes do build de release para rejeições 2.1 e configure uma conta demo para o revisor. Depois, percorra o checklist de envio para o próximo build. Se a mensagem de revisão ainda deixar você travado, envie os detalhes para nós e ajudamos a descobrir se o que falta é acesso, metadados ou código.