Uma rejeição na App Store exige uma resposta adequada ao problema citado. Comece pela mensagem da revisão e verifique o que falhou. As orientações atuais da Apple permitem responder após correções de informações, metadados ou acesso no servidor; uma correção ao código da build enviada exige uma nova build. Se contestar a decisão, esclareça-a antes de recorrer.
Reenviar imediatamente pode reiniciar um trabalho que poderia ter resolvido na conversa.
Começamos por colocar a mensagem ao lado da app enviada e registar o que o revisor conseguiu ver. Assim, terá uma tarefa concreta para discutir com o programador, mesmo que não consiga alterar o código por sua conta.
O que diz realmente a sua rejeição na App Store?
Leia o estado e o elemento afetado antes de escolher uma correção. A referência de estados da Apple distingue um envio que aguarda revisão de uma app rejeitada ou de informações de ficha rejeitadas. Um envio pode incluir vários elementos. Registe qual deles tem o problema, a diretriz citada e a explicação do revisor; um simples aviso de rejeição antigo não fornece informação suficiente para agir.
Os metadados são as informações da ficha, como descrições e capturas de ecrã, que ficam fora do pacote executável da app. Uma build é a versão empacotada enviada para revisão. As App Review Guidelines da Apple tratam a integridade, a exatidão dos metadados e a funcionalidade suficiente da app como requisitos distintos. Uma descrição mais clara não corrige uma falha da app, enquanto uma funcionalidade operacional pode continuar a exigir melhores informações para a revisão.
Mantenha um registo da tarefa com estes campos: elemento afetado, diretriz, problema observado, correção proposta, provas, pessoa responsável e ação seguinte. Use a preocupação efetivamente indicada pelo revisor. Se a mensagem não explicar algum aspeto, marque o campo como desconhecido e faça depois uma pergunta específica.
Encontre o problema que o revisor conseguiu reproduzir
Teste a versão enviada, começando pelo ponto descrito na mensagem. A sua conta habitual pode já ter acesso ou uma configuração concluída que o revisor não tem. As orientações de preparação da Apple pedem credenciais de demonstração funcionais e as informações necessárias para chegar às funcionalidades da app. Verifique o percurso completo antes de pedir uma nova versão ao programador.
- Confirme a versão e o ambiente. Pergunte ao programador qual foi a build enviada e em que dispositivo e sistema operativo foi testada. A ajuda da Apple sobre testes em dispositivos exige testes em dispositivos físicos, incluindo os modos de compatibilidade relevantes. Registe tudo o que não conseguir reproduzir nos dispositivos disponíveis.
- Experimente a conta de revisão com uma nova sessão. Siga os passos fornecidos até à funcionalidade comunicada. Verifique as funções da conta e quaisquer instruções relativas a códigos de autenticação. A ajuda da Apple sobre uma revisão completa pede estes dados antecipadamente; as credenciais têm de continuar utilizáveis quando a revisão começar.
- Leia a ficha ao lado da app. Compare as capturas de ecrã e a descrição com aquilo que essa build realmente faz. Se a rejeição disser respeito a uma mensagem de permissão, as orientações da Apple sobre a descrição da finalidade exigem uma explicação concreta de como a app usa o recurso solicitado.
- Verifique o comportamento de privacidade citado. Se o problema estiver relacionado com a eliminação de contas, teste o percurso real. As orientações da Apple exigem que as apps que permitem criar contas ofereçam o início da eliminação dentro da app; a simples desativação não é suficiente. As obrigações de conservação e as exceções para apps regulamentadas exigem uma verificação própria.
Use uma conta de teste com dados de exemplo seguros. Uma gravação ou um anexo deve mostrar o percurso que falhou ou foi corrigido sem expor registos de clientes nem credenciais.
Responder, enviar uma nova build ou recorrer?
Escolha a via depois de saber o que mudou. A ajuda da Apple sobre estados de revisão distingue as correções que podem ser explicadas numa resposta das alterações que exigem outra revisão. A tabela ajuda a decidir perante uma rejeição existente; um aviso de remoção ou uma ação sobre a conta exige um processo próprio.
| Situação | Próxima ação suportada |
|---|---|
| Informação em falta, metadados corrigidos ou uma correção do acesso no servidor | Corrija o problema e responda no App Store Connect |
| Foi corrigido um defeito na build enviada | Carregue a build alterada e envie-a para uma nova revisão |
| Considera que a decisão aplica incorretamente a regra citada | Esclareça a questão na conversa e recorra se não ficar resolvida |
A Apple avisa que um reenvio inicia uma nova revisão e encerra as respostas à mensagem anterior. Reenviar durante um recurso encerra esse recurso. Confirme com a pessoa responsável pela conversa antes de alterar o envio.
Uma oferta explícita de Bug Fix Submission é um caso distinto. A ajuda da Apple limita-a a atualizações elegíveis de apps anteriormente aprovadas, sem problemas jurídicos ou de segurança. A aceitação é feita por resposta, com o compromisso de corrigir os problemas na atualização seguinte. Leia a oferta antes de usar a via normal de uma nova build.
Prepare a correção e as provas em conjunto
Associe cada problema a uma correção e a uma forma de a verificar. Mantemos a tarefa do programador e a resposta ao revisor ligadas ao mesmo registo, para que uma alteração à app se reflita nas informações enviadas com ela. Comece pelas verificações que pode fazer por sua conta e atribua depois as alterações de código ao programador.
- Elimine lacunas de acesso e informação. Atualize as notas da revisão com a finalidade da app, as funcionalidades alteradas, os serviços externos e as diferenças regionais quando forem relevantes, seguindo a ajuda da Apple sobre uma revisão completa. Volte a testar as credenciais depois de as alterar.
- Verifique o site associado. Abra num telemóvel os URL de suporte e privacidade indicados no envio. Compare o destino e a redação com a app em revisão. Esta verificação de coerência pode integrar o trabalho de desenvolvimento de sites quando um site dá suporte a uma app.
- Peça uma correção técnica demonstrável. Perante um problema da build, peça ao programador que mostre o percurso comunicado depois da correção e identifique a build que a contém. Esta passagem de trabalho faz parte do desenvolvimento e publicação de aplicações móveis, em conjunto com a preparação para a revisão.
- Envie uma resposta específica. As instruções de resposta da Apple usam a ligação de problemas não resolvidos da app e, depois, In Progress, Resolve e Reply to App Review. É necessário ter acesso como Account Holder, Admin ou App Manager. Explique o problema, onde encontrar a correção e como testá-la; anexe provas relevantes se forem úteis e selecione depois Reply.
- Use um recurso para uma divergência que se mantenha. A ajuda da Apple sobre recursos pede que esclareça primeiro a questão e que depois responda aos requisitos citados com provas. Inclua no recurso todas as violações indicadas para essa app. Um pedido de atualização do estado ou de revisão mais rápida deve seguir outra via.
Não coloque palavras-passe pessoais da Apple no registo da tarefa. Mantenha a conta de programador sob o controlo da empresa e use o acesso adequado ao trabalho de cada pessoa.
Como saber se o problema está resolvido?
Distinga uma correção que testou da decisão da Apple. Volte a executar exatamente o mesmo percurso depois da alteração e guarde o resultado, a versão da build ou das informações e a resposta enviada. Consulte depois o estado atual no App Store Connect. Um teste local bem-sucedido informa apenas sobre esse teste; a decisão sobre o envio continua a pertencer à Apple.
Acompanhe se existem provas para cada problema citado, se o acesso para a revisão continua a funcionar e se uma mensagem posterior repete a mesma preocupação. Se isso acontecer, compare a nova mensagem com o seu registo antes de fazer outra alteração. Depois de a app ser lançada, conseguir downloads da app é uma tarefa distinta.
Onde intervimos
Começamos pela mensagem de rejeição, pela versão enviada e por um percurso reproduzível na app. Podemos então separar as correções da ficha e do site do trabalho de desenvolvimento e preparar as informações destinadas ao revisor. Antes de aceitar outra build, entregue estes materiais à pessoa responsável pelo lançamento, com as perguntas ainda por resolver devidamente assinaladas.
