Por que a Apple reprova apps Flutter feitos com IA, e o que resolve de verdade

Você sobe o build na sexta. Na segunda aparece uma mensagem no App Store Connect com o número de uma diretriz e um parágrafo que parece falar de outro app. Você corrige o que acha que ele quis dizer, reenvia e espera mais um dia.

A maioria dos apps feitos rápido com IA bate nesse muro pelo mesmo motivo: a ferramenta otimizou para a demo. A revisão faz o contrário. O revisor instala um build de release num aparelho que você não testou, nega todas as permissões, procura o botão de excluir a conta e compara as suas capturas de tela com o que o app faz de verdade.

Estas são as reprovações que mais se repetem em apps Flutter, e o que resolve cada uma.

Diretriz 2.1: o revisor não conseguiu usar o app

É a mais comum, e quase nunca é um crash que acontece no seu celular.

O revisor não conseguiu entrar. Se alguma parte fica atrás de login, a seção App Review Information precisa de uma conta de demonstração que funcione, e o backend precisa estar no ar quando ele testar. Usuário de teste expirado é reprovação.
Foi testado num iPad. O template de iOS do Flutter suporta iPhone e iPad por padrão. Se você nunca abriu o app num iPad, o revisor pode ser a primeira pessoa a ver o layout quebrar. Ou faça funcionar, ou tire o iPad dos dispositivos suportados no Xcode, de propósito.
O build de release se comporta diferente. O modo debug perdoa muita coisa: roda asserts, compila na hora e esconde problemas de tempo. Rode flutter run --release num aparelho físico antes de cada envio. Uma quantidade surpreendente de crashes "que no meu funciona" só existe em release.
Conteúdo provisório. Lorem ipsum, aba "em breve", botão que não faz nada. O que parece inacabado é lido como inacabado.

Diretriz 5.1.1: privacidade e permissões

Ferramentas de IA adicionam pacotes sem cerimônia, e cada pacote pode trazer junto uma permissão, um SDK de rastreamento ou uma obrigação de privacidade.

Justificativas vagas. NSCameraUsageDescription com "Este app precisa da câmera" é reprovado. Diga para que a câmera é usada, nas palavras do usuário: "Usada para ler o QR code do seu ingresso."
Permissões que você não usa. Se o Info.plist pede localização porque uma dependência mencionou, o revisor vai perguntar por quê. Tire o que não precisa.
Sem como excluir a conta. Se o usuário cria conta dentro do app, ele precisa conseguir iniciar a exclusão dentro do app também. Não por e-mail para o suporte, não só pelo site.
Privacy manifest. A Apple exige um manifesto de privacidade dos apps e de vários SDKs de terceiros que usam certas APIs do sistema. Versões antigas de plugins muitas vezes não trazem esse arquivo, e o envio é sinalizado antes mesmo da revisão. Atualizar o plugin costuma ser a correção inteira, o que é um bom motivo para não deixar as dependências paradas por um ano.

Diretriz 3.1.1: vender coisa digital sem compra dentro do app

Se o app libera conteúdo ou funcionalidade digital, a Apple espera In-App Purchase. Um checkout do Stripe dentro de uma WebView, ou um botão que manda o usuário pagar no seu site, é reprovação clássica.

As regras sobre links de pagamento externo mudaram em alguns países, incluindo a loja dos EUA em 2025, então confira a diretriz atual para cada país onde você vende. O que não mudou: se você usa In-App Purchase, o app precisa de um jeito visível de restaurar compras. Paywall gerado por IA quase nunca tem.

Diretriz 4.8: login com Google, mas não com Apple

Se o app oferece login por um serviço de terceiros como Google ou Facebook, a Apple espera uma opção equivalente que limite a coleta de dados e deixe o usuário esconder o e-mail. O Sign in with Apple atende. Colocar login com Google numa tarde e esquecer disso é uma das reprovações mais previsíveis que existem.

Diretriz 4.2: é um site dentro de uma caixa

Um app que embrulha um site numa WebView, sem nada que use o aparelho, é reprovado por funcionalidade mínima. Isso pega muito build rápido, porque embrulhar o sistema web que já existe é o caminho mais curto para "temos um app". Se o produto é de fato um site, um site mobile bem feito pode servir melhor. Se precisa ser app, ele precisa fazer algo que app faz: acesso offline, notificação, câmera, alguma coisa nativa.

Diretriz 2.3: as capturas de tela prometem outra coisa

Capturas feitas no Figma antes do app ficar pronto, funcionalidade listada na descrição que foi cortada, a palavra "Android" em qualquer lugar dos metadados. O revisor compara a página da loja com o app. Faça a página descrever o build que você está enviando, não o roadmap.

Como parar de ir e voltar

Antes de enviar, faça o que o revisor vai fazer:

Instale o build de release num iPhone físico e, se você suporta, num iPad.
Comece de uma instalação limpa e negue todas as permissões. O app ainda precisa abrir e explicar o que não consegue fazer.
Crie uma conta e depois exclua de dentro do app.
Se tem paywall, encontre o restaurar compras sem ajuda.
Coloque uma conta de demonstração que funcione e instruções curtas nas notas da revisão, e mantenha essa conta viva.
Leia as capturas e a descrição contra o build, linha por linha.

Quando a reprovação vier, leia o número da diretriz antes do parágrafo. O número diz a categoria do problema; o parágrafo muitas vezes é um texto padrão. Responda no Resolution Center se achar que o revisor entendeu errado. Uma explicação clara e educada resolve mais reprovação do que se imagina.

Quando ela continua voltando

Se você está na terceira reprovação pela mesma diretriz, o problema costuma ser estrutural: uma dependência que não atualiza sem quebrar o build, um fluxo de pagamento que precisa ser refeito, um login que não se encaixa nas regras. É aí que remendar o parágrafo que a Apple mandou para de funcionar.

É exatamente para isso que existe o nosso resgate de app: um diagnóstico de preço fechado, um plano escrito do que mudar e as correções, se você quiser que a gente faça.