A Guideline 2.1 — Performance: App Completeness cobre situações em que o app não funciona corretamente durante a revisão da Apple. O revisor testa o app em dispositivos reais — se o app travar, não carregar ou exigir acesso que o revisor não consegue obter, a rejeição é automática.
Causas mais comuns da rejeição 2.1
1. App fecha inesperadamente (crash)
O app crasha ao abrir, em alguma tela específica, ou ao realizar uma ação. Pode ser por força em produção, variável não inicializada, chamada de API sem fallback de erro, ou incompatibilidade com a versão do iOS usada pelo revisor.
✅ Correção: teste o build exato que foi enviado (não o de debug) em dispositivo físico com o iOS mais recente. Use o Xcode Organizer para verificar crash logs do build rejeitado. Adicione tratamento de erro em todas as chamadas de rede e force unwraps.
2. Tela em branco ou spinner infinito
O app abre mas fica carregando indefinidamente, ou exibe uma tela branca. Causa frequente: o app aponta para um servidor de staging que não está respondendo em produção, ou há dependência de dados locais que não existem no dispositivo do revisor.
✅ Correção: certifique-se de que o build enviado usa a URL de produção, não de staging/desenvolvimento. Adicione timeout nas chamadas de rede e trate o estado de erro com uma mensagem visível ao usuário — não apenas um spinner sem fim.
3. Login obrigatório sem credenciais de demo
O app exige login para funcionar, mas o revisor não tem como criar uma conta ou não tem credenciais fornecidas. O revisor não vai criar conta própria — se não tiver acesso, rejeita por app "incompleto".
✅ Correção: no App Store Connect, preencha o campo "Notes for Reviewer" com login e senha de uma conta de demonstração funcional. A conta precisa ter acesso a todas as funcionalidades do app (não pode estar em estado vazio ou "novo usuário" que não demonstra o app).
4. Funcionalidades dependentes de hardware não disponível
O app usa câmera, GPS, NFC, ARKit ou outro hardware que o dispositivo de teste do revisor pode não ter. O app crasha ao tentar acessar o hardware.
✅ Correção: verifique disponibilidade do hardware antes de acessá-lo (AVCaptureDevice.authorizationStatus, CLLocationManager.authorizationStatus, etc.) e forneça fallback gracioso quando não disponível. Mencione nos Notes for Reviewer quais funcionalidades exigem hardware específico.
5. Funcionalidades bloqueadas por geolocalização
O app só funciona em certas regiões geográficas, e o revisor (nos EUA) não consegue acessar funcionalidades disponíveis apenas no Brasil ou em outros países.
✅ Correção: explique nos Notes for Reviewer que algumas funcionalidades são restritas por região e forneça um modo de demonstração ou VPN para o revisor testar. Alternativamente, desative temporariamente as restrições geográficas durante a revisão.
Como evitar a rejeição 2.1 antes de submeter
5 itens para verificar antes de enviar
1. Teste o build de produção (archive do Xcode) em dispositivo físico — nunca apenas no simulador.
2. Confirme que o app aponta para servidores de produção, não staging.
3. Preencha os campos "Notes for Reviewer" com login/senha de demo e qualquer instrução necessária.
4. Teste com conexão de internet lenta (simule via Xcode → Device Conditions → Network Link Conditioner).
5. Teste em iPhone SE (menor tela) e no iPhone mais recente — o revisor pode usar qualquer um.
💡 Use o TestFlight com beta externos antes de submeter. Se beta testers conseguem usar o app sem problemas, a chance de passar na revisão é muito maior.
⚠️ Se o revisor não conseguiu completar uma ação específica, a mensagem da rejeição geralmente descreve exatamente o que aconteceu. Leia com atenção — às vezes é um problema pontual fácil de corrigir, não um crash geral.
Rejeição 2.1 travando seu lançamento?
A AtlasTech identifica a causa raiz da rejeição, aplica a correção e acompanha até a aprovação — sem tentativas às cegas.
Quero resolver a rejeiçãoVeja também: Outras rejeições comuns da Apple · Guideline 4.0 — Design · Guideline 5.1 — Privacidade · TestFlight