Neste guia
Um build rápido não é problema para o revisor. O que faz os apps voltarem é o que um build rápido costuma deixar inacabado: conteúdo de teste esquecido, funcionalidades rasas, informação de privacidade faltando. Esta página relaciona esses itens com a redação oficial, para que você possa conferi-los antes de enviar. Não sabemos como os revisores trabalham por dentro e não fazemos suposições.
A autoverificação, relacionada às diretrizes
1. Texto de espaço reservado e conteúdo temporário
Apple, diretriz 2.1 (Completude do app): as submissões "should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission." (devem ser versões finais, com todos os metadados necessários e URLs totalmente funcionais; texto de espaço reservado, sites vazios e outros conteúdos temporários devem ser eliminados antes do envio.)
Verificação: pesquise no projeto por "lorem", "TODO", "test", "example.com". Abra cada link do app e da ficha (URL de suporte, URL de privacidade, URL de marketing) em um celular.
2. Falhas e problemas técnicos evidentes
A mesma diretriz diz: "Make sure your app has been tested on-device for bugs and stability before you submit it... We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems." (Certifique-se de que seu app foi testado no dispositivo quanto a bugs e estabilidade antes de enviá-lo... Vamos rejeitar pacotes e binários incompletos que falhem ou apresentem problemas técnicos evidentes.)
Verificação: instale o build de lançamento, não o de depuração, em um celular real. Passe pela primeira abertura, pelo cadastro, pelo fluxo principal e por um reinício. Veja teste em dispositivo real e como ler relatórios de falhas.
3. Login sem um jeito de entrar
A diretriz 2.1 também pede que você "include demo account info (and turn on your back-end service!) if your app includes a login." (inclua as informações de uma conta de demonstração (e ligue seu serviço de back end!) se o app tiver login.)
Verificação: crie uma conta de demonstração, coloque os dados nas notas para o revisor e confirme que seu back end está rodando quando você enviar.
4. Política de privacidade ausente
Diretriz 5.1.1(i): "All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner." (Todos os apps devem incluir um link para a política de privacidade no campo de metadados do App Store Connect e dentro do app, de forma facilmente acessível.) A política deve dizer quais dados são coletados e como são usados.
Verificação: o link funciona, é acessível dentro do app e corresponde ao que o app realmente coleta, incluindo dados coletados por bibliotecas ou serviços que você adicionou. Sem aconselhamento jurídico aqui; consulte um profissional se tiver dúvidas.
5. App pouco desenvolvido
Diretriz 4.2 (Funcionalidade mínima): o app "should include features, content, and UI that elevate it beyond a repackaged website." (deve incluir funcionalidades, conteúdo e UI que o elevem além de um site reempacotado.)
Verificação: pergunte a outra pessoa o que o app faz que uma página web não faria. Se a resposta for fraca, adicione uma funcionalidade real antes de enviar.
6. Google Play
A ajuda de Segurança dos dados do Google diz que todos os desenvolvedores com um app publicado no Google Play devem preencher o formulário de Segurança dos dados, que as declarações devem corresponder ao comportamento real do app, incluindo bibliotecas e SDKs de terceiros, e que uma política de privacidade é obrigatória. Se seu app permitir criar conta, a ajuda do Google sobre exclusão de conta pede um caminho de exclusão dentro do app e um link web para pedidos de exclusão. A Apple também exige exclusão de conta dentro do app (diretriz 5.1.1(v)). Confira as páginas atuais do Google antes de enviar.
Antes de apertar enviar
- Build de lançamento em um celular real, com a passagem completa feita
- Nenhum conteúdo de espaço reservado, todos os links abrem
- Link da política de privacidade na ficha e no app
- Conta de demonstração nas notas para o revisor, back end rodando
- Uma frase de resposta para "o que este app faz?"
Para mais sobre a própria verificação, veja motivos de rejeição na App Store e como testar. Se uma rejeição vier mesmo assim, trate-a como feedback: leia, corrija o ponto citado e use este modelo de prompt se você trabalha com um assistente de código.
Onde a AppReviewX se encaixa
A maior parte da lista acima é encontrada mais rápido por alguém que não construiu o app. A AppReviewX oferece feedback privado e estruturado de outros desenvolvedores: um feedback que você escreve rende um crédito, os créditos compram feedback sobre o seu app, e contas novas começam com 0 créditos. Para Android há grupos de teste para o requisito do Google Play de 12 testadores por 14 dias seguidos.
Relacionados: central de vibe coding, ciclo de feedback com seu assistente de código.
As políticas mudam; confira as diretrizes citadas. Não é aconselhamento jurídico.