erberkk/review-readiness

Prontidão para Revisão

Propósito

Envie uma vez e passe. A maioria das rejeições não é sobre a ideia do aplicativo; é um revisor que não conseguiu fazer login, não conseguiu comprar, viu um placeholder ou encontrou uma contradição entre os metadados e o aplicativo.

Pré-requisitos

• A build exata a ser enviada está no TestFlight / em uma faixa de teste do Play.
• O checkpoint subscriptions-and-payments foi aprovado (uma compra real desbloqueou o premium em ambas as plataformas).
• privacy-and-declarations concluído; validador listing-and-aso limpo; capturas de tela enviadas.

Pense como um revisor sem conhecimento prévio

Assuma que o revisor instala uma build limpa em um dispositivo que você não testou (um app somente iPhone pode ser revisado em um iPad em modo de compatibilidade), com uma conta nova da loja e tem tempo limitado. Eles leem suas notas, tentam fazer login, procuram pela compra e comparam as capturas de tela com o aplicativo. Uma única rejeição pode combinar várias camadas: estado da conta, comportamento do backend e metadados.

Procedimento

1. Conta demo

• As credenciais vão para App Store Connect › App Review Information ("Sign-in required") e Play › App content › App access. Nunca no repositório.
• A conta faz login com e-mail + senha. Se seu login normal é um código único por e-mail ou magic link, o revisor não consegue recebê-lo. Adicione um caminho de senha apenas para o endereço de revisão (lista de permissão no servidor) ou um código de teste fixo que funcione apenas para esse endereço.
• Preenchida com dados: perfil completo, alguns dias de histórico, cada tela principal populada. Uma conta vazia esconde recursos e convida a "não conseguimos localizar o recurso X".
• Premium desbloqueado por meio de uma permissão manual no servidor (sem expiração durante a revisão), para que os revisores vejam os recursos pagos sem comprar.
• Separadamente, garanta que um novo usuário possa acessar o paywall e comprar com a conta sandbox do revisor (eles testarão a compra também).
• Não altere, exclua ou re-semeie esta conta enquanto uma revisão estiver aberta.

2. Compras (2.1(b) e 3.1.x)

• As assinaturas da primeira versão são anexadas à versão no App Store Connect (seção "In-App Purchases and Subscriptions") e têm uma captura de tela de revisão e notas. Na interface mais recente do App Store Connect pode não haver essa seção na página da versão: abra o grupo de assinaturas e cada assinatura e use Add for Review → Draft Submission; a versão em si é adicionada de sua própria página. O rascunho deve listar a versão, o grupo e cada assinatura antes de você pressionar Submit for Review.
• Cada assinatura precisa de pelo menos uma localização de nome de exibição + descrição e uma captura de tela de revisão; sem elas, "Add for Review" falha ("You must add at least one subscription localization / a Review Information screenshot").
• A captura de tela de revisão deve mostrar o paywall real com preços reais e a redação correta da loja. Se você renderizá-la a partir de um widget/teste de interface, force a plataforma iOS (caso contrário, dirá "Google Play") e forneça preços realistas da loja; um estado "preços indisponíveis" não é aceitável.
• A string de versão do App Store deve ser igual à versão de marketing da build (CFBundleShortVersionString). Uma versão chamada 1.0 não oferecerá builds carregadas como 1.0.0; a seção Build apenas diz "Upload your builds" sem botão Add Build. Renomeie a versão para corresponder.
• No TestFlight com uma nova conta Apple sandbox (não vinculada a nenhuma das suas contas de aplicativo): os produtos carregam, a compra funciona, a restauração funciona.
• O estado de erro do paywall mostra tentar novamente, nunca um "Em breve" desabilitado.
• Se uma compra dentro do aplicativo não puder ser acessada no aplicativo (por exemplo, apenas para uma região), explique o motivo nas notas de revisão.
• Restaurar Compras, links de Termos e Privacidade, link de gerenciar assinatura presentes.

3. Dispositivos e builds

• Inicialização a frio sem rede, rede lenta e modo avião ativado: sem travamentos, sem spinner infinito.
• iPad: mesmo um aplicativo somente iPhone é executado no iPad em modo de compatibilidade e pode ser revisado lá. Execute o fluxo completo em um simulador de iPad: login (incluindo Sign in with Apple), rolagem do paywall, folha de compra, teclado sobre formulários, prompts de permissão, rotação. Se HealthKit ou outra API estiver indisponível lá, mostre uma mensagem educada, não um travamento.
• Menor telefone suportado e maior tamanho de texto: nenhum botão cortado no paywall ou nas telas de consentimento.
• Build de lançamento, não de depuração: sem banner de depuração, sem menus de teste, análises/relatórios de falhas ativos na configuração de produção.
• Percorra todo o ciclo de vida da conta em um dispositivo físico com a build exata que você enviará: instalar, cadastrar, recursos principais, compra sandbox, exclusão de conta e o que o aplicativo mostra após a exclusão.

4. Conteúdo e metadados

• Pesquise nas strings e listagens do aplicativo por: TODO, lorem, coming soon, beta, test, [PRICE], imagens placeholder. Nenhum pode ser renderizado.
• A build e os metadados do iOS não contêm redação do Android / Google Play; o Play não contém redação exclusiva da Apple (2.3.10). Inclui strings no aplicativo como "Cancelar na App Store ou Google Play" — escolha o texto da plataforma em tempo de execução.
• Cada captura de tela corresponde à interface atual; cada número na descrição corresponde ao aplicativo.
• As URLs de política de privacidade, termos, suporte e exclusão de conta carregam sem login, mencionam o aplicativo e correspondem aos formulários de privacidade.
• Classificação indicativa consistente com os Termos.

5. Backend

• O backend está ativo e em um plano que não atingirá limites durante a revisão (níveis gratuitos pausando ou limitando = rejeição).
• Sem implantações de mudanças significativas durante a revisão. API compatível com versões anteriores para a build em revisão.
• Alertas estão ativos (post-launch-ops) para que você perceba uma interrupção durante a revisão.

6. Notas de revisão

Preencha templates/review-notes.md. Mantenha-se factual: onde os recursos estão, como fazer login, como testar a compra, como os dados de IA e saúde são tratados, onde está a exclusão de conta.

A Apple pode responder com a Diretriz 2.1 "Information Needed" em vez de revisar. Em um caso observado, pediu os seis itens abaixo; respondê-los antecipadamente na primeira submissão evita uma viagem de ida e volta:

1. Uma gravação de tela de um dispositivo físico no SO mais recente, começando na inicialização do aplicativo e mostrando o fluxo típico: registro, login, exclusão de conta, qualquer conteúdo gerado pelo usuário com relatório/bloqueio e acesso ao conteúdo pago. Grave com a build enviada; anexe o arquivo à resposta na seção Messages da submissão (ou link) e mencione-o nas Notas. Nunca use a conta demo de revisão para a parte de exclusão: crie uma conta nova na gravação.
2. O propósito e o público-alvo do aplicativo: o problema que ele resolve e seu valor.
3. Instruções de configuração e acesso para os principais recursos, com credenciais demo e caminhos de menu.
4. Cada serviço externo por trás dos recursos principais: autenticação/banco de dados, pagamentos (StoreKit + qualquer wrapper), provedores de IA, fontes de dados (ex. APIs de mapa), e-mail, frameworks de saúde.
5. Diferenças regionais ou uma declaração de que os recursos são os mesmos em todos os lugares.
6. Para áreas regulamentadas ou conteúdo protegido de terceiros: documentação ou uma declaração de que nada se aplica (ex. "bem-estar geral, não um dispositivo médico").

7. Relatório go/no-go

Preencha templates/go-no-go-report.md com evidências para cada linha (captura de tela, número da build, saída de comando). Qualquer Não em uma linha impeditiva significa nenhuma submissão.

8. Enviar (APROVAÇÃO)

Peça ao titular da conta aprovação explícita com o relatório anexado. No iOS, escolha lançamento manual para que a aprovação não publique imediatamente. No Play, o acesso de produção (novas contas pessoais) precisa do teste fechado de 14 dias concluído e da inscrição de acesso de produção primeiro.

Após uma rejeição

Consulte references/rejection-playbook.md: leia a diretriz exata, reproduza, corrija a causa raiz (geralmente mais de uma camada), responda no Resolution Center com detalhes, reenvie; recorra apenas quando o revisor interpretou mal um fato que você pode provar.

Pontos de decisão que precisam de aprovação humana

Enviar, escolher o método de lançamento, responder a uma rejeição (tom e compromissos), entrar com um recurso, conceder premium à conta de revisão.

Verificação

O relatório go/no-go está completo com evidências, e alguém que não construiu o recurso seguiu as notas de revisão em um dispositivo limpo e obteve sucesso.

Armadilhas comuns

• A conta demo depende de um código de e-mail que o revisor não pode ler.
• Conta demo vazia, congelada ou excluída por um trabalho de limpeza.
• Produtos em "Missing Metadata" (sem captura de tela de revisão), então nunca carregam na revisão.
• Remover uma versão da revisão ("Developer Rejected") também remove as assinaturas do rascunho; adicione novamente o grupo e cada assinatura antes de reenviar, ou a versão vai sozinha.
• Os assets da página do produto ficam bloqueados enquanto a versão está "Waiting for Review" (ex. o novo asset Header). Adicione tudo antes de enviar; caso contrário, você deve remover a versão da revisão, editar e reenviar (você perde seu lugar na fila).
• A própria verificação "Add for Review" da Apple ser aprovada não significa que os assets opcionais estão definidos: um asset Header vazio é permitido, então decida sobre ele antes de enviar.
• A nova conta Apple de um revisor entra em conflito com suas regras de restauração/transferência e a compra "falha".
• Backend em um plano que pausa após inatividade ou limita o revisor.
• "Em breve" em qualquer lugar da build.
• Texto no aplicativo mencionando a outra loja.
• Notas de revisão que apenas explicam o login demo (sem gravação, propósito, serviços ou regiões).