App rejeitado pela Apple: 5 casos reais e como corrigir

Uma rejeição da Apple quase sempre tem um motivo preciso, escrito na mensagem da revisão: uma guideline numerada, muitas vezes acompanhada de uma captura de tela. Os motivos mais comuns para um primeiro app são um app que não está terminado (2.1), privacidade mal declarada (5.1.1), metadados enganosos (2.3.2), um pagamento que contorna a compra in-app (3.1.1) ou um pedido de avaliação no lugar errado (5.6.3). Na grande maioria dos casos, o reviewer entendeu seu app direitinho: o problema é que o seu envio dava margem para crítica.

Eu sei disso porque levei essas rejeições na pele. Publico meus próprios apps iOS: Solys (um despertador com minijogos) e TradaZen (um simulador de trading) estão na App Store. O Solys levou duas rejeições, uma antes do lançamento e outra numa atualização, e outros dois apps, Clic e Nolera, foram rejeitados, corrigidos e reenviados para a Apple. Aqui estão as cinco rejeições, a causa real de cada uma, depois o método para responder e o checklist que aplico antes de cada envio.

Por que a Apple rejeita um app: as 5 rejeições que eu levei

Rejeição 2.1 no Solys: era impossível vencer a demo

O onboarding do Solys oferece uma demo jogável: você precisa vencer um minijogo, como na hora de acordar. Nos meus celulares, tudo funcionava. Já o reviewer testava num iPad, onde um app de iPhone roda em modo de compatibilidade numa janela menor. Nesse tamanho, a passagem deixada para o passarinho do minijogo ficava mais estreita que o próprio passarinho, e o botão “Continuar” só acendia em caso de vitória. A Apple pediu uma forma de pular a missão do jogo.

A correção: uma demo cuja geometria é calculada a partir do tamanho real da tela, e um link para pular a demo em caso de derrota.

A lição: toda etapa obrigatória precisa ter uma saída, e cada tela obrigatória deve ser testada no menor formato possível antes de cada envio.

Rejeição 5.6.3 no Solys: o pedido de avaliação durante o onboarding

Segunda rejeição, na atualização seguinte. A Apple escreveu que o app pedia uma avaliação na primeira abertura ou durante o onboarding. A tela de avaliação aparecia logo depois da demo, antes de o usuário ter vivido qualquer coisa no app.

A correção: o pedido foi para o fim do fluxo, e só aparece se o usuário acabou de vencer a demo.

A lição: todo pedido sensível (avaliação, notificação, assinatura, rastreamento) vem depois de uma prova de valor, nunca antes.

Rejeição 5.1.1 no Clic: a política de privacidade online estava desatualizada

O Clic gera conteúdo com IA, e o app tinha sim sua tela de consentimento. O problema estava em outro lugar: a política de privacidade publicada no site era a versão antiga, e não descrevia tudo o que o app coleta.

A correção: política completa publicada, resumo em inglês adicionado, notas de revisão atualizadas.

A lição: a Apple lê a sua política online, não a que está parada no seu repositório. Antes de cada envio, abra a URL declarada e confira se ela diz o que o seu app faz.

Rejeição 5.1.1 no Nolera: um botão “Permitir” antes do pedido do sistema

Antes do pedido real de acesso à câmera do iOS, o Nolera mostrava uma tela explicativa com um botão “Permitir”. Para a Apple, esse texto induz o usuário a aceitar antes do pedido oficial do sistema.

A correção: o botão agora se chama “Continuar”, nos 8 idiomas do app.

A lição: uma tela que prepara uma permissão explica, ela não decide no lugar do usuário. As recomendações da Apple estão nas suas regras de design sobre privacidade.

Rejeição 2.3.2 no Nolera: o ícone reaproveitado como imagem promocional

As assinaturas podem ter uma imagem promocional no App Store Connect. Em duas assinaturas do Nolera, era simplesmente o ícone do app. A Apple considerou isso fora das regras.

A correção: as imagens foram removidas das duas assinaturas, e o envio foi recriado.

A lição: cada elemento da sua página é examinado, inclusive os que você preenche sem pensar, como a classificação etária.

Quais guidelines derrubam apps com mais frequência?

Todas as regras estão nas App Review Guidelines. As que mais pegam um primeiro app:

2.1: App Completeness. O app trava, um botão não leva a lugar nenhum, uma tela obrigatória não funciona em algum formato. Se o seu app exige login, forneça uma conta de demonstração nas notas de revisão, senão o reviewer fica travado na tela de login. Tudo o que você precisa saber sobre esse motivo está no meu guia da guideline 2.1.

2.3: Metadata. Capturas que não mostram o app real, descrição que promete uma função que não existe, imagens promocionais fora das regras.

3.1.1: In-App Purchase. Para desbloquear conteúdo ou funções digitais no app, a regra geral é a compra in-app da Apple. As exceções dependem do país e mudam com o tempo: leia a versão atualizada das guidelines antes de planejar outro meio de pagamento. O passo a passo completo está na página assinaturas in-app no iOS.

3.1.2: Subscriptions. Um app com assinatura precisa mostrar com clareza o que o usuário recebe e por qual preço. Os erros clássicos de tela de pagamento estão em paywall iOS: 7 erros de iniciante.

4.3: Spam. O app se parece com mil outros ou não entrega o suficiente por si só. É a rejeição mais difícil de corrigir: ela se previne já na escolha da ideia. Explico em detalhes no guia da guideline 4.3.

5.1.1: Privacy. Declarações de coleta que não batem com o comportamento do app, política de privacidade incompleta, permissão pedida sem explicação clara.

Como responder a uma rejeição da Apple sem perder dias?

Uma rejeição não é um veredito, é um vai e volta. O procedimento que funciona:

1. Leia o motivo duas vezes. A mensagem cita a guideline e muitas vezes traz uma captura de tela. Muitos desenvolvedores respondem fora do ponto porque leram rápido demais.
2. Procure a causa real. Tanto no Clic quanto no Nolera, a causa real não era a que o texto sugeria à primeira vista. Reproduza o problema nas condições do reviewer: mesmo tipo de aparelho, conta nova, primeira abertura.
3. Corrija o motivo, e nada além. Não é hora de adicionar três funções: cada mudança aumenta a superfície de revisão.
4. Responda no App Store Connect. Explique em duas frases objetivas o que você corrigiu, respondendo à mensagem do App Review.
5. Só recorra se tiver certeza. A Apple permite acionar o App Review Board se você acha que seu app foi mal compreendido, com um único recurso por envio rejeitado. Contestar uma rejeição merecida só faz você perder tempo.

Quanto ao prazo, a Apple diz analisar pelo menos 50% dos envios em menos de 24 horas, e 90% em menos de 48 horas. São as rejeições que atrasam o cronograma, não a fila de espera: os detalhes estão em prazo de aprovação na App Store. O passo a passo completo depois de uma rejeição está na página app rejeitado pela Apple.

Uma rejeição evitável custa um ciclo de revisão completo. A melhor resposta para a Apple é o envio que não deixa nada para ela apontar.

O checklist que aplico antes de cada envio

Construído rejeição após rejeição, nos meus apps:

• Cada tela obrigatória testada no menor iPhone, no maior e no iPad em modo de compatibilidade, seguindo a grade da guideline 4.0 design
• Uma saída possível em cada etapa do onboarding, mesmo em caso de falha
• Conta de demonstração nas notas de revisão se o app tem login
• Compras testadas em sandbox, incluindo a restauração
• Preço, duração e links para os termos e a privacidade presentes onde a Apple exige, em cada idioma
• Política de privacidade online relida no dia do envio
• Declarações de privacidade alinhadas com o que o app realmente coleta, incluindo o privacy manifest
• Telas antes da permissão sem botão “Permitir”
• Pedidos de avaliação e de notificação colocados depois de uma prova de valor, sem desbloquear nada em troca de uma avaliação (guideline 3.2.2)
• Imagens promocionais e capturas que mostram o app real, inclusive nas suas páginas de produto personalizadas

Se é a sua primeira publicação, a página publicar um aplicativo na App Store reúne todas as etapas antes do envio.

Um modelo para explicar seu fluxo ao App Review

Baixe o modelo de notas para o App Review: instruções em francês, notas em inglês para completar e um roteiro de resposta a uma rejeição. Ele faz você especificar a versão, o caminho pelas telas e o resultado esperado. Mantenha só o que existe na sua build.

Troque “o app salva corretamente” por um cenário reproduzível: tela inicial, ação, fechar e reabrir, resultado encontrado. Depois de uma rejeição, cite o comportamento corrigido e o aparelho em que você conferiu. Se você não conseguiu reproduzir o problema, explique o que falta para reproduzi-lo.

As credenciais de uma conta de demonstração vão nos campos próprios do App Store Connect, nunca num arquivo público. Você pode preparar as provas com a grade de testes do TestFlight e encontrar os cinco modelos gratuitos.

Evitar essas rejeições antes do envio

O Apple Review Kit reúne meu checklist antes do envio, minhas rejeições da Apple corrigidas e skills do Claude Code que revisam seu projeto, seu paywall e sua página antes do envio.

Seu app já foi rejeitado? O kit ajuda você a encontrar a regra citada, o que ela exige e um exemplo de correção e de resposta. Se quiser que a gente analise seu caso juntos agora mesmo, reserve uma hora comigo, por videochamada.

Ninguém pode garantir que a Apple vai aceitar seu app. Partir de rejeições já vividas simplesmente reduz as chances de você cair nas mesmas.

Ainda não enviou seu app? O diagnóstico gratuito manda para você meu checklist anti-rejeição da Apple e diz o que ainda falta fazer. Se você ainda está construindo, a página inicial mostra como criar um aplicativo mobile já pensando nessas rejeições.

Perguntas frequentes

Por que meu aplicativo foi rejeitado pela Apple?

Quase sempre por um motivo preciso, escrito na mensagem da revisão: uma guideline numerada, muitas vezes acompanhada de uma captura de tela. Para um primeiro app, os motivos mais comuns são um app que não está terminado (2.1), privacidade mal declarada (5.1.1) e metadados enganosos (2.3.2). Também aparecem um pagamento que contorna a compra in-app (3.1.1) e um pedido de avaliação no lugar errado (5.6.3).

Por que meu app foi rejeitado se ele funciona no meu iPhone?

Porque o reviewer pode testar em condições diferentes das suas. No Solys, meu despertador com minijogos, ele testava num iPad, onde um app de iPhone roda em modo de compatibilidade numa janela menor. Lá, era impossível vencer a demo. A correção: uma demo calculada a partir do tamanho real da tela, e um link para pulá-la em caso de derrota.

O que fazer quando a Apple rejeita meu aplicativo?

Leia o motivo duas vezes e depois procure a causa real reproduzindo o problema nas condições do reviewer: mesmo tipo de aparelho, conta nova, primeira abertura. Corrija o motivo e nada além, porque cada mudança aumenta a superfície de revisão. Em seguida, responda no App Store Connect, em duas frases objetivas sobre o que você corrigiu.

Dá para contestar uma rejeição da Apple?

Sim, mas só se você tiver certeza do que está dizendo. A Apple permite acionar o App Review Board se você acha que seu app foi mal compreendido, com um único recurso por envio rejeitado. Contestar uma rejeição merecida só faz você perder tempo. Caso contrário, corrija o motivo e responda no App Store Connect.

Uma rejeição aumenta o prazo de publicação?

Sim. A Apple diz analisar pelo menos 50% dos envios em menos de 24 horas, e 90% em menos de 48 horas: então são as rejeições que atrasam o cronograma, não a fila de espera. Uma rejeição evitável custa um ciclo de revisão completo. Os detalhes dos prazos estão em prazo de aprovação na App Store.

O que conferir antes de enviar um app para a Apple?

Teste cada tela obrigatória no menor iPhone, no maior e num iPad em modo de compatibilidade, depois teste as compras em sandbox, incluindo a restauração. Releia sua política de privacidade online no dia do envio e forneça uma conta de demonstração nas notas de revisão se o app tem login. Esse checklist foi construído rejeição após rejeição, nos meus apps.