Rejeição 2.1 App Completeness na App Store: teste o build de release antes de reenviar (2026)

Uma rejeição na App Store pela diretriz 2.1 App Completeness significa que o revisor não conseguiu usar seu app como um cliente usaria. Ele pode ter travado, mostrado conteúdo placeholder, bloqueado o revisor numa tela de login ou escondido uma compra no app. A correção raramente é uma única linha de código. Antes de reenviar, rode um plano de teste curto no build de release, usando uma instalação limpa e as mesmas credenciais que você fornece à App Review. Este post mostra esse plano passo a passo e como outros desenvolvedores resolveram a mesma rejeição.

O que a diretriz 2.1 App Completeness da App Store verifica?

A diretriz 2.1 verifica se o build enviado é um app finalizado e funcionando. Ele precisa de metadados completos, links que funcionam, um login demo, um backend no ar e compras no app que o revisor consiga encontrar e usar.

As App Review Guidelines da Apple dividem a 2.1 em duas partes. A 2.1(a) diz que os envios "devem ser versões finais com todos os metadados necessários e URLs totalmente funcionais" e que textos placeholder e sites vazios devem ser removidos. Ela também pede que você teste num dispositivo em busca de bugs e problemas de estabilidade, e que "inclua os dados de uma conta demo (e ligue seu serviço de backend!) se o app tiver login". A Apple "rejeitará pacotes de app incompletos e binários que travem ou apresentem problemas técnicos óbvios". A 2.1(b) diz que as compras no app devem estar "completas, atualizadas, visíveis para o revisor e funcionais". Se uma compra configurada não puder ser encontrada no app, explique o motivo nas notas para a revisão.

Essa rejeição é comum. A página Preparing for App Review da Apple diz: "Em média, mais de 40% dos problemas não resolvidos estão relacionados à diretriz 2.1: App Completeness, que cobre travamentos, conteúdo placeholder, informações incompletas e mais."

Por que testar o build de debug não pega problemas da 2.1?

Um build de debug não roda do jeito que a cópia do revisor vai rodar. O revisor instala um build de release assinado para distribuição num dispositivo limpo, sem sessão salva e sem atalhos de debug.

Seu simulador já está logado. Sua API local pode apontar para um servidor de staging que nunca cai. Flags de debug pulam o paywall, e feature flags vêm ativadas por padrão. O revisor não tem nada disso. A página de revisão da Apple também pede que você "teste minuciosamente em dispositivos com o software mais recente", então o revisor pode estar num iOS mais novo que o do seu celular de testes.

O TestFlight é o mais perto que você chega do ambiente do revisor. Segundo a visão geral do TestFlight, você pode adicionar até 100 testadores internos da sua equipe no App Store Connect e até 10.000 testadores externos. Um build pode ser testado por até 90 dias. Envie exatamente o build que pretende submeter, instale-o pelo TestFlight num dispositivo que nunca rodou o app e teste essa cópia.

O que um plano de teste do build de release deve cobrir antes de reenviar?

Um plano de teste do build de release verifica todos os pontos em que um revisor começando do zero pode travar: abertura do app, permissões, login, backend, conteúdo, links, compras, falhas de rede e iPad. Siga os passos em ordem no build do TestFlight e anote cada resultado para poder citá-lo nas notas para a revisão.

1. Instalação limpa no iOS mais recente. Apague qualquer cópia anterior, instale pelo TestFlight e abra sem nenhum estado salvo. Faça três aberturas a frio e confirme que o onboarding não trava.
2. Negue cada pedido de permissão uma vez. Recuse notificações, localização, câmera e rastreamento. O app ainda deve chegar a uma tela utilizável. Confirme também que o Info.plist tem uma descrição de uso para cada recurso protegido que o app ou seus SDKs usam.
3. Entre com as credenciais demo exatas. Copie-as do App Store Connect, não do seu gerenciador de senhas. A conta deve ter dados realistas, não deve exigir verificação de e-mail e não deve usar autenticação de dois fatores ligada ao seu próprio celular.
4. Confirme que o backend é o de produção e está no ar. O build precisa apontar para os endpoints de produção. Rate limits, listas de IPs permitidos e bloqueio geográfico não podem barrar o revisor. A diretriz 2.1(a) manda você ligar seu serviço de backend.
5. Percorra todas as abas e telas. Procure lorem ipsum, telas de "Em breve", estados vazios sem explicação, imagens de teste e botões que não fazem nada.
6. Toque em todos os links. Isso inclui política de privacidade, suporte, termos e quaisquer web views. A Apple diz: "Um link para o suporte ao usuário com informações de contato atualizadas e um link para sua política de privacidade são obrigatórios para todos os apps."
7. Abra cada compra no app. Entre com uma conta nova. Verifique se cada produto enviado com a versão aparece com preço, pode ser comprado no sandbox e se Restaurar Compras funciona.
8. Teste numa rede lenta ou instável. Ative o modo avião no meio de um fluxo. Uma mensagem de erro clara é aceitável. Um spinner que nunca para, ou um travamento, não é.
9. Verifique o iPad se você oferece suporte a ele. Se o app roda no iPad, abra-o lá e garanta que o layout não deixe o usuário preso.

A conta demo do passo 3 causa mais rejeições repetidas do que qualquer outro passo. Nosso guia sobre como configurar uma conta demo para a revisão da App Store explica como montar uma que dure.

Como relacionar a mensagem de rejeição 2.1 com a correção certa?

Para relacionar uma rejeição 2.1 a uma correção, leia a frase depois do número da diretriz. Ela descreve o sintoma, e cada sintoma aponta para um passo do plano de teste.

Imagine que um app de acompanhamento de hábitos seja rejeitado com a mensagem "We were unable to review the app because it crashed on launch" (não foi possível revisar o app porque ele travou ao abrir). Uma segunda nota diz que o revisor não conseguiu localizar as compras no app. A tabela abaixo relaciona sintomas comuns a uma causa, um teste e uma correção.

Para um método mais amplo de interpretar qualquer mensagem de rejeição, veja Rejeição na App Store: como corrigir, diretriz por diretriz.

Como foram as rejeições 2.1 de outros desenvolvedores?

Casos públicos de 2.1 seguem o mesmo padrão. O app funciona no ambiente do desenvolvedor e falha para o revisor por causa de algo que só uma instalação limpa ou o login de um estranho revelaria.

• Travamento por falta de descrição de uso. Nos fóruns do Solar2D, um desenvolvedor recebeu a mensagem "We were unable to review the app because it crashed on launch" num iPhone 13 mini com iOS 18.3.2, embora o app rodasse no TestFlight. Outro membro encontrou isto no log de travamento anexado: "Este app travou porque tentou acessar dados sensíveis de privacidade sem uma descrição de uso." O desenvolvedor relatou: "Passou depois de adicionar: NSUserTrackingUsageDescription."
• Logins sociais que o revisor não conseguiu usar. Um desenvolvedor nos Apple Developer Forums relatou rejeições 2.1 repetidas porque os revisores "não conseguiram usar os logins sociais". Ele tinha fornecido contas demo da Apple e do Google, mas o login com Apple ID exigia um código de verificação enviado ao celular do desenvolvedor. A equipe da Apple respondeu que a App Review entraria em contato diretamente. Nenhuma solução pública foi publicada.
• Compras no app que "não puderam ser encontradas no binário enviado". Num tópico da comunidade RevenueCat, um desenvolvedor foi rejeitado porque um plano mensal não foi encontrado no binário, mesmo com as compras no sandbox funcionando. Um participante contou que uma rejeição parecida foi resolvida respondendo com um passo a passo detalhado e capturas de tela de todos os caminhos até o paywall. A equipe da RevenueCat recomendou mostrar todos os produtos enviados no paywall padrão e manter os arquivos de teste do StoreKit fora do scheme de Archive.

Nos três casos, os testes do próprio desenvolvedor passaram. A falha só apareceu a partir do ponto de partida do revisor: sem celular para o 2FA, sem sessão anterior e sem saber onde ficava o paywall. É esse ponto de partida que o plano de teste acima recria.

O que escrever nas notas para a App Review depois de uma rejeição 2.1?

As notas para a revisão depois de uma rejeição 2.1 devem trazer credenciais demo que funcionem, listar o que mudou desde o build rejeitado e dizer exatamente onde encontrar as compras no app e qualquer recurso pouco óbvio.

A página de revisão da Apple orienta a colocar os dados da conta e configurações especiais na seção App Review Information. Se um recurso exige hardware ou um ambiente difícil de montar, "esteja preparado para fornecer um vídeo de demonstração ou o hardware". A diretriz 2.3.1(a) acrescenta que novos recursos devem ser descritos "com especificidade" nas Notes for Review e que "descrições genéricas serão rejeitadas". Uma nota curta e estruturada funciona bem:

Demo account: review@example.com / (password)
Account is pre-verified, has no 2FA and has 30 days of sample data.

Fixes since last submission (2.1):
- Launch crash on fresh install fixed (tested build 42 on latest iOS, clean device).
- In-app purchases: Settings > Upgrade shows Monthly and Yearly.
- Backend is production and will stay live during review.

Non-obvious features:
- Widgets: long-press Home Screen > add "Streaks" widget.

Se obrigações legais ou de segurança impedem uma conta demo, a diretriz 2.1(a) permite um modo demo embutido, mas só com aprovação prévia da Apple, e esse modo precisa mostrar todos os recursos e funcionalidades do app. Não troque para um modo demo sem essa aprovação.

Como reenviar ou recorrer de uma rejeição 2.1?

Para reenviar depois de uma rejeição 2.1, envie ou selecione o build que você testou, responda à App Review no App Store Connect com o que mudou, atualize as notas para a revisão e submeta de novo. Só recorra se você acredita que o revisor entendeu o app errado.

1. Confira se o número do build vinculado à versão no App Store Connect é o mesmo do build do TestFlight que você testou.
2. Responda à mensagem de rejeição com um resumo curto de cada correção. Para problemas de compra ou navegação, inclua instruções passo a passo e capturas de tela.
3. Atualize a seção App Review Information com credenciais e notas atuais.
4. Envie para revisão. Em outubro de 2026, a Apple diz que normalmente analisa "pelo menos 50% dos envios em menos de 24 horas e 90% em menos de 48 horas".

Se você acredita que a Apple errou, a página da App Review permite recorrer ao App Review Board. Dê motivos específicos que mostrem que o app está em conformidade e "envie apenas um recurso por envio que não passou na revisão". Numa rejeição 2.1, porém, reproduzir o problema num dispositivo limpo costuma ser mais rápido do que argumentar. Se preferir delegar o reenvio, nosso serviço de envio para a App Store cobre a preparação para a revisão e o tratamento de feedback de rejeição nas duas lojas por US$ 599, com as taxas da conta de desenvolvedor à parte.

Problemas da 2.1 costumam voltar em atualizações futuras: uma nova feature flag, uma chave de API trocada ou uma conta demo expirada. Inclua este plano de teste na sua rotina de release, junto com o checklist de envio para a App Store. Em atualizações, um lançamento em fases limita quantos usuários um bug que escapou atinge. Para uma segunda opinião sobre um build rejeitado, envie a mensagem de rejeição para yagyeshsrbobde@gmail.com.