Uma rejeição na App Store chega como uma mensagem no App Store Connect: um número de diretriz, algumas frases do revisor, muitas vezes uma captura do ecrã que falhou. Não é um veredicto sobre a sua app nem sobre a sua conta. O App Review da Apple tratou mais de 9,1 milhões de envios em 2025, a maioria em menos de 24 horas, e uma boa parte dos primeiros envios volta pelo menos uma vez. O que conta é o que faz na hora que se segue à mensagem.
Essa decisão resume-se a três perguntas. O revisor tem razão? A correção exige um novo build, ou apenas uma alteração à ficha? E, se discordar, responde ou recorre? Este guia responde-lhes por ordem: como uma rejeição lhe chega e o que significam os estados, os oito motivos que cobrem a maioria das rejeições, as três respostas possíveis, e um checklist para o reenvio.
Se estiver mais atrás no percurso, o nosso guia sobre como publicar uma app na App Store cobre todo o caminho, da conta de programador ao lançamento; este artigo começa no dia em que a revisão volta negativa.
Como uma rejeição lhe chega e o que significam os estados
O App Review combina verificações automáticas, que apanham crashes, uso de APIs privadas e malware, com um revisor humano que instala o seu build, abre a ficha, lê as suas notas de revisão e usa a app como um cliente o faria. Quando algo falha, o revisor escreve uma mensagem no Resolution Center do App Store Connect e a versão muda de estado. Três estados importam:
- Rejected. O próprio binário tem um problema: um crash, uma funcionalidade em falta, um problema de permissões. Vai quase sempre precisar de enviar um novo build.
- Metadata Rejected. O build está bem; a ficha não. Capturas de ecrã, descrição, palavras-chave, respostas de privacidade ou notas de revisão precisam de uma alteração, que faz diretamente no App Store Connect antes de reenviar sem um novo build.
- Developer Rejected. Retirou a versão por iniciativa própria, por exemplo para substituir um build. Não há nada a responder.
Os oito motivos por trás da maioria das rejeições num primeiro envio
As App Review Guidelines têm cinco capítulos e dezenas de regras, mas as rejeições que um primeiro envio recebe de facto concentram-se numa mão-cheia delas. Aqui ficam, com o que o revisor viu e o que resolve o problema.
| Diretriz | O que o revisor viu | O que resolve |
|---|---|---|
| 2.1 Performance | A app falhou ao arrancar ou num fluxo central no dispositivo do revisor | Reproduza no binário do TestFlight, em vários dispositivos e versões de iOS, e corrija. Envie um novo build. |
| 2.1 App completeness | Uma conta de demonstração que não funciona, conteúdo provisório, uma funcionalidade marcada como «brevemente» | Forneça um início de sessão funcional com dados realistas em App Review Information; retire ou termine os elementos provisórios. |
| 2.3 Accurate metadata | As capturas de ecrã ou a descrição mostram funcionalidades que não estão no build | Metadata Rejected: atualize as capturas e o texto para corresponderem à app, reenvie o mesmo build. |
| 4.2 Minimum functionality | Um site numa moldura, ou uma app que faz demasiado pouco para justificar uma instalação nativa | Acrescente valor nativo: uso offline, notificações, funções do dispositivo, uma experiência que o site não oferece. |
| 4.3 Spam | Uma app que duplica outra, sua ou de um modelo, numa categoria saturada | Diferencie-a de forma substancial, ou funda as variantes numa única app. |
| 5.1.1 Data collection and storage | URL da política de privacidade em falta, etiquetas App Privacy que contradizem a app, pedidos de permissão sem justificação, pedido de rastreio em falta | Publique a política, alinhe as etiquetas com o que a app recolhe de facto, escreva um texto de justificação para cada permissão, mostre o pedido App Tracking Transparency se fizer rastreio. |
| 3.1.1 In-app purchase | Conteúdo digital ou subscrições vendidos fora da compra integrada da Apple | Use a compra integrada para bens digitais; o pagamento externo continua permitido para bens físicos e serviços consumidos fora da app. |
| 1.5 Developer information | Uma URL de suporte que devolve um erro ou uma página sem forma de o contactar | Metadata Rejected: aponte a URL de suporte para uma página ativa com um formulário de contacto ou um e-mail. |
O caso especial dos sites embrulhados
A diretriz 4.2 é a que surpreende os fundadores que empacotaram o seu site numa app. A posição da Apple é consistente: se a app é o site numa WebView sem nada que o browser não pudesse fazer, não tem lugar na App Store. A correção não é uma descrição melhor; é funcionalidade. Acesso offline, notificações push, funções de câmara ou localização, uma navegação nativa que o site não tem. Se o projeto começou como uma app web, o caminho honesto é um verdadeiro build nativo, e é por isso que o nosso guia sobre criar uma app móvel sem programar separa as ferramentas que geram código nativo das que embrulham um site.
Como responder: corrigir, responder ou recorrer
Ler a mensagem como um checklist
Antes de decidir seja o que for, extraia da mensagem o número da diretriz, o passo exato que o revisor descreve, o dispositivo e a versão de iOS indicados no topo, e qualquer captura anexada. Depois reproduza-o no mesmo build através do TestFlight. Metade das vezes o revisor tem razão e não tinha reparado; um quarto das vezes o revisor caiu num contexto que não testou, como uma instalação nova sem dados; o resto é um desacordo genuíno.
Corrigir e reenviar
Para um estado Metadata Rejected, edite a ficha no App Store Connect e clique em reenviar: sem novo build, e a segunda revisão costuma ser rápida. Para um estado Rejected, envie um build corrigido, selecione-o na mesma versão e submeta de novo. Em ambos os casos, escreva uma nota curta no Resolution Center a dizer o que mudou. Os revisores leem-na, e ela orienta a segunda revisão para a correção em vez de recomeçar do zero.
Responder quando o revisor está errado
Se não conseguir reproduzir o problema ou se a diretriz não se aplicar, responda no Resolution Center em vez de reenviar o mesmo build em silêncio. Seja factual: os passos exatos que seguiu, o dispositivo e a versão, uma gravação de ecrã que mostre a funcionalidade a funcionar, as credenciais a usar. Se o revisor percebeu mal o que a app faz, explique o caso de uso em duas frases. Pode também pedir uma chamada telefónica do App Review na mesma conversa; não é rápido, mas desbloqueia as conversas que o texto não consegue resolver.
Recorrer para o App Review Board
Um recurso serve para um desacordo sobre a própria diretriz, não sobre um facto. Vai para o App Review Board através do formulário ligado à rejeição, e demora dias, por vezes mais. Use-o depois de a resposta no Resolution Center ter falhado, e escreva-o para alguém que nunca viu a sua app: o que faz, que diretriz foi citada, porque acredita que não se aplica. Se a diretriz mudou recentemente, ou se acha que está a ser aplicada de forma incoerente, diga-o e dê exemplos.
Revisão acelerada
A Apple concede uma revisão acelerada para a correção de um bug crítico numa app já publicada ou para um evento com data marcada, não para um primeiro lançamento atrasado. Pedir uma para um lançamento é recusado e faz perder um dia. Se o seu prazo é real, a única alavanca é enviar cedo e responder a qualquer mensagem em poucas horas.
Um checklist para evitar a segunda rejeição
A maioria das segundas rejeições repete a primeira, ou expõe o problema seguinte a que o revisor não chegou porque o primeiro travou a revisão. Antes de reenviar, percorra esta lista uma vez:
- O binário do TestFlight abre numa instalação nova, sem dados, na versão de iOS mais antiga que suporta.
- A conta de demonstração em App Review Information inicia sessão, e os dados por trás dela parecem reais.
- Cada pedido de permissão tem um texto de justificação que diz o que a funcionalidade faz com os dados.
- A URL da política de privacidade abre, e as respostas App Privacy correspondem aos SDKs presentes na app.
- As capturas de ecrã mostram ecrãs que existem neste build, nos tamanhos de dispositivo certos.
- Qualquer compra digital passa pela compra integrada, e qualquer compra física é claramente física.
- A URL de suporte e a URL de marketing carregam e oferecem uma forma de o contactar.
- Textos provisórios, botões de teste e ecrãs «brevemente» desapareceram.
- As notas de revisão explicam tudo o que sai do comum: um requisito de hardware, uma funcionalidade limitada a uma região, um início de sessão através de um serviço terceiro.
Se constrói com o criador de apps móveis da Cadrant, as partes do pipeline que causam rejeições ao nível do build ficam tratadas por si: o binário nativo é compilado e assinado na sua conta Expo, entregue ao seu App Store Connect, e a app é uma verdadeira aplicação Expo e não um site embrulhado, o que deixa a diretriz 4.2 fora de cena. O que continua a ser seu é exatamente este checklist: a ficha, as respostas de privacidade, a conta de demonstração e uma passagem pelo TestFlight antes de carregar em enviar. A documentação de publicação lista os passos no App Store Connect por ordem.
Em resumo
- Uma rejeição é uma mensagem com um número de diretriz; o estado diz-lhe se a culpa é do build ou da ficha.
- Oito diretrizes explicam a maioria das primeiras rejeições: crashes, conta de demonstração, metadados, funcionalidade mínima, spam, privacidade, compra integrada, URL de suporte.
- Corrija e reenvie quando o revisor tem razão, responda com provas quando os factos estão errados, recorra apenas quando é a própria diretriz que está em causa.
- Responda no próprio dia, e percorra o checklist antes de cada reenvio.
Gerida assim, uma rejeição custa um ou dois dias, não um lançamento. As apps que ficam bloqueadas são as que reenviam o mesmo build à espera de um revisor diferente.