Guideline 2.1: entender e corrigir uma rejeição na App Store

A guideline 2.1 é a regra que mais derruba envios. A própria Apple diz isso na página App Review: em média, mais de 40% dos problemas não resolvidos envolvem a 2.1, a que cobre crashes, conteúdo provisório e informações incompletas.

Este artigo trata só dessa regra: o que ela cobre, suas duas variantes, como o reviewer testa seu app e o que responder a ele, com três rejeições que levei nos meus próprios apps. Para uma visão geral de todos os motivos de rejeição, leia por que a Apple rejeita um app.

O que é a guideline 2.1 App Completeness?

A guideline 2.1 exige que o app enviado à Apple seja uma versão final e completa: sem crash, sem link quebrado, sem texto provisório, com uma conta de demonstração se o app pedir login, e com compras no app visíveis e funcionando. Se o reviewer não conseguir percorrer o app até o fim, é rejeição 2.1.

O texto oficial está nas App Review Guidelines, seção 2 "Performance". Ele se divide em duas alíneas.

2.1(a) pede que cada envio seja uma versão final, com todos os metadados e URLs funcionando. Texto provisório, sites vazios e qualquer conteúdo temporário precisam sumir antes do envio. O app precisa ter sido testado em um aparelho real quanto a bugs e estabilidade. Se ele pede login, você fornece uma conta de demonstração e deixa seu servidor ligado. Um modo demo integrado pode substituir essa conta, mas só com autorização prévia da Apple, e ele precisa mostrar todas as funções do app. A frase que resume tudo: "We will reject incomplete app bundles and binaries that crash".

2.1(b) trata das compras no app: elas precisam estar completas, atualizadas, visíveis para o reviewer e funcionando. Se uma compra configurada no App Store Connect não aparece no app, você precisa explicar o motivo nas notas de revisão.

O que a guideline 2.1 cobre na prática

Na prática, uma rejeição 2.1 cai por um destes motivos:

• Um crash. Na abertura, depois de uma permissão negada, sem internet. Basta um.
• Um link quebrado. Privacidade, termos de uso, suporte: cada URL declarada vai ser aberta.
• Uma função inacessível. Um botão que não leva a lugar nenhum, uma tela obrigatória impossível de passar, um onboarding sem saída. A forma mais traiçoeira: invisível no seu próprio celular.
• Uma conta de demonstração ausente ou expirada. O reviewer fica travado na tela de login, ou a conta fornecida não funciona mais, ou o servidor está desligado.
• Conteúdo de preenchimento. Lorem ipsum, "Em breve", tela vazia, dados de teste visíveis.
• Compras no app que não aparecem. A assinatura existe no App Store Connect, mas o reviewer não encontra a tela que a vende, ou a compra falha no sandbox. Os erros de tela de pagamento mais comuns estão em paywall iOS: 7 erros de iniciante.

2.1 Information Needed ou 2.1(a): qual a diferença?

As mensagens da Apple não têm todas o mesmo título, e a diferença muda a sua resposta.

"Guideline 2.1 - Information Needed" significa que o reviewer não conseguiu terminar a revisão e está te fazendo uma pergunta. Falta um login, uma explicação, um jeito de chegar a uma função. Ainda não é a constatação de um bug: é um pedido. Às vezes, uma resposta precisa no App Store Connect resolve. Mas se a pergunta revelar um bloqueio real no app, você precisa de um novo build.

"Guideline 2.1(a) - Performance - App Completeness" significa que o reviewer encontrou um problema: um crash, um bug, uma tela que não responde. A mensagem costuma indicar o aparelho usado e muitas vezes traz uma captura de tela. Aí você precisa corrigir, enviar um novo build e depois responder.

Como a Apple testa seu app

Coloque-se no lugar do reviewer. Três pontos importam.

Ele testa em um aparelho que talvez você não tenha. A mensagem de rejeição muitas vezes informa o modelo. A regra 2.4.1 diz que apps de iPhone devem rodar no iPad sempre que possível, e um app feito para iPhone aparece nele em modo de compatibilidade, numa janela no formato do iPhone. Minhas rejeições 2.1 recentes vieram de um iPad Air: se você só testa no seu iPhone, não vê o que o reviewer vê.

Ele começa de uma primeira abertura. App novo, sem cache, sem sessão, sem nenhuma atualização baixada.

A rede precisa funcionar só com IPv6. A regra 2.5.5, vizinha da guideline 2.5.4 sobre modos em segundo plano, exige que o app funcione plenamente em uma rede só IPv6, e a página de suporte da Apple sobre IPv6 torna isso obrigatório para todos os apps enviados desde 1º de junho de 2016. O risco vem de um endereço IPv4 escrito direto no código: a Apple recomenda testar numa rede só IPv6, com os dados móveis desligados.

Para reproduzir essas condições antes do envio, o TestFlight em vários aparelhos continua sendo o mais simples: veja TestFlight: testar seu app de iPhone.

Três rejeições que levei, e a causa real

Três rejeições recentes nos meus próprios apps, com a causa real.

Solys: uma demo de minijogo impossível de vencer no iPad

Solys é o meu despertador com minijogos. Em 18 de agosto de 2026, um build foi rejeitado com "2.1 Information Needed": a Apple pedia um jeito de passar a missão do jogo. O reviewer testava num iPad Air, com o app de iPhone em modo de compatibilidade.

A causa real estava na demo de minijogo do onboarding. As alturas dos obstáculos estavam fixas em pontos. Com a altura de card disponível no iPad em compatibilidade, a passagem ficava mais estreita que o personagem: era impossível vencer a demo. E o botão "Continuar" só acendia em caso de vitória. Nenhuma saída: o reviewer não conseguia ver o app.

A correção: uma geometria proporcional ao tamanho medido do card, e um link "Pular demo" que aparece depois de uma derrota.

A lição: toda etapa travada por desempenho precisa ter uma saída incondicional. E cada tela obrigatória deve ser testada na menor tela suportada E no iPad em modo de compatibilidade.

Nolera: uma correção invisível para o reviewer

Em 17 de setembro de 2026, Nolera foi rejeitado depois de uma revisão num iPad Air. A mensagem combinava a 2.1(a) com outros pontos. A correção do problema apontado tinha sido entregue por atualização remota (OTA), sem novo build.

O problema: na primeiríssima abertura, o reviewer vê o código embutido no build, não a atualização baixada depois. Para ele, a correção não existia.

A lição: uma correção destinada à revisão precisa estar no binário enviado à Apple.

Clic: a causa não estava no app

Em 16 de setembro de 2026, Clic foi rejeitado. O app em si estava atualizado. A causa real estava em outro lugar: a política de privacidade publicada online não estava atualizada quanto ao provedor de IA usado. Essa rejeição tem mais a ver com privacidade do que com a 2.1, mas ilustra a mesma coisa: a causa real nem sempre é a que a mensagem dá a entender.

A lição: confira o que está online, não o que está no seu repositório. Abra cada URL declarada no dia do envio.

O que responder no Resolution Center

Depois de uma rejeição, seu envio passa para "Unresolved Issues" e a conversa com a Apple acontece na seção App Review do seu app, que ainda chamam de Resolution Center. O procedimento oficial para responder ao App Review permite uma mensagem de no máximo 4.000 caracteres, com um anexo.

Escreva em inglês, de forma objetiva. O reviewer quer três informações: o que travava, o que mudou, como verificar. Este é o modelo que eu uso (troque o número do build e a correção pelos seus):

Hello,

Thank you for your review.

Issue: the onboarding game demo could not be completed on iPad
(iPhone app running in compatibility mode), so the user could
not continue.

Fix in build 1.0.3 (42):
- The game layout now scales to the measured screen size.
- A "Skip demo" link appears after a failed attempt, so the
  onboarding can always be completed.

How to verify: launch the app, start the onboarding demo,
lose once, then tap "Skip demo".

A screen recording is attached.

Best regards,

Algumas regras:

• Responda à pergunta feita. Num "Information Needed", comece pela resposta exata, não pelo contexto.
• Informe o build e dê o caminho até a tela corrigida, em três ou quatro ações.
• Anexe uma prova. Um vídeo curto num aparelho parecido com o do reviewer evita mais uma ida e volta.
• Nada de defesa apaixonada. A apelação ao App Review Board existe, mas numa rejeição 2.1 merecida ela só aumenta a espera. Os detalhes dos prazos estão em prazo de aprovação na App Store.

Se o motivo continuar confuso depois de ler, o passo a passo completo está na página app rejeitado pela Apple.

Notas de revisão e conta de demo

A seção App Review Information da sua versão, no App Store Connect, é sua melhor defesa contra a 2.1. Segundo a referência oficial desses campos, ela contém:

• Sign-in required: o login e a senha de uma conta de demonstração. Essa conta não pode expirar. Se seu app usa um login de terceiros, forneça as credenciais desse serviço.
• Notes: até 4.000 bytes, no idioma que você quiser. Tudo o que ajude a testar.
• Contact: um nome, um e-mail e um número no formato internacional.

O que eu sempre coloco nas notas:

1. O caminho até cada compra no app, como pede a regra 2.1(b).
2. As funções não óbvias: um gesto, uma permissão, um conteúdo ligado a um horário.
3. O estado da conta de demo: assinante ou não, dados pré-preenchidos ou vazios.
4. As limitações conhecidas: para um hardware ou ambiente difícil de reproduzir, a Apple pede que você esteja pronto para fornecer um vídeo.

E uma regra fora do formulário: deixe seu servidor ligado durante toda a revisão. Um servidor de teste desligado é uma conta de demo que não funciona mais, ou seja, uma rejeição 2.1.

O checklist 2.1 antes do envio

O que eu aplico antes de cada envio, montado a partir das minhas rejeições:

• App instalado do zero no menor iPhone suportado, no maior e num iPad em modo de compatibilidade
• Onboarding percorrido inteiro, falhando de propósito em cada etapa que exige desempenho
• Cada tela obrigatória com uma saída incondicional
• Nenhuma correção destinada à revisão entregue só por atualização remota
• App aberto em modo avião e depois numa rede só IPv6
• Cada URL declarada aberta no próprio dia: privacidade, termos, suporte
• Nenhum texto provisório, tela vazia ou dado de teste visível
• Conta de demo testada no dia do envio, sem data de expiração, servidor ligado
• Cada compra no app encontrada a partir do app e testada no sandbox, incluindo a restauração
• Notas de revisão indicando onde estão as compras e as funções não óbvias

Se é sua primeira publicação, todas as etapas anteriores estão em publicar um app na App Store.

Envie seu pacote com alguém que já levou essas rejeições

O Apple Review Kit reúne meu checklist antes do envio, os modelos de notas para o reviewer e skills do Claude Code que revisam seu projeto antes de você enviar.

Acabou de receber uma rejeição 2.1? O kit também te ajuda a encontrar a regra citada, o que ela exige e um exemplo de correção e de resposta. Se quiser que a gente olhe seu caso juntos agora mesmo, reserve uma hora comigo, por videochamada.

Ninguém pode garantir que a Apple vai aceitar seu app. O que eu posso fazer é te ajudar a evitar as rejeições 2.1 que já me custaram um ciclo de revisão.

Ainda não enviou seu app? O diagnóstico gratuito te manda meu checklist anti-rejeição da Apple, regra 2.1 incluída, e diz o que falta fazer antes do envio. Se você ainda está construindo, a página inicial mostra como criar um aplicativo móvel com a revisão em mente desde o começo.

Perguntas frequentes

O que significa "Guideline 2.1 - Information Needed"?

O reviewer não conseguiu terminar a revisão e está te fazendo uma pergunta: um login, uma explicação, um jeito de acessar uma função. Responda com precisão no App Store Connect. Se a pergunta revelar um bloqueio real no app, como no Solys, corrija e envie um novo build.

Preciso de um novo build depois de uma rejeição 2.1?

Para um crash, um bug ou uma tela que trava, sim: a correção precisa estar no binário. Uma atualização remota não basta, porque o reviewer vê o código embutido na primeira abertura. Para uma simples informação faltando, uma resposta pode bastar.

Meu app pede login: o que fornecer ao reviewer?

Uma conta de demonstração que não expira, informada na seção App Review Information, e um servidor ligado durante toda a revisão. Um modo demo integrado só pode substituir essa conta com autorização prévia da Apple, e ele precisa mostrar todas as funções.

Uma rejeição 2.1 pode vir de algo além do app?

Sim. Uma URL quebrada na página do app, uma conta de demo expirada, um servidor desligado ou uma compra no app mal configurada já bastam. E às vezes, como no Clic, a causa real está online e não no código: confira tudo o que o reviewer pode abrir.