Porque é que a revisão da app está a demorar tanto?

Uma revisão lenta não significa automaticamente que seu aplicativo tem um problema. Aprenda a distinguir um atraso na fila de um envio bloqueado, o que a Apple e o Google realmente prometem e quando entrar em contato com o suporte.

Carregou a build, verificou as capturas de ecrã e planeou o lançamento. Depois, nada acontece. O App Store Connect continua a dizer Aguardando Revisão, ou a Play Console mantém as suas alterações em revisão. Entretanto, cada dia de incerteza torna mais difícil coordenar o marketing, o apoio ao cliente e o anúncio de lançamento.

A parte frustrante é que um atraso tem várias explicações possíveis. A sua submissão pode simplesmente estar à espera da sua vez. Um revisor pode precisar de informações. A sua compilação pode nem ter chegado à revisão. Ou a revisão pode já ter terminado, com a publicação à sua espera. Este guia explica como distinguir essas situações. Foca-se na Apple App Review, com uma comparação separada com o Google Play. As fontes foram verificadas em 3 de outubro de 2026.

Quanto tempo deve demorar a revisão da app?

A Apple diz que, em média, 90% dos envios são revisados em menos de 24 horas. Isso é um contexto útil, mas não é um prazo garantido para seu aplicativo individual. Alguns envios ficam fora dessa janela, e a estatística não fornece um tempo de conclusão para essas exceções. A Apple também alerta que envios incompletos podem atrasar a revisão. [1]

Trate esse número como uma referência de planeamento, não como um compromisso de lançamento. Uma submissão que demore mais de um dia não é, por si só, evidência de rejeição ou de uma conta avariada. Da mesma forma, uma média não deve persuadi-lo a ignorar uma mensagem acionável. O estado e a correspondência do revisor importam mais do que comparações com a aprovação mais rápida de outro programador.

Primeiro, identifique onde está realmente o atraso

Leia o estado preciso em vez de traduzir cada indicador amarelo para “A Apple está a rever a minha app.” À espera de revisão significa que a submissão está na fila; Em revisão significa que a revisão começou. Pendente de Lançamento do Programador significa que a app foi aceite mas ainda precisa da sua ação de lançamento. À espera de Conformidade de Exportação é um processo diferente. Um item aceite também pode permanecer não publicado se outro item na sua submissão foi rejeitado. [2]

Verifique a versão da app e a submissão em conjunto, não apenas a compilação carregada. Uma captura de ecrã da lista de compilações pode contar uma história diferente da página de submissão. Anote a versão, o número da compilação, a hora da submissão e o estado atual. Esse pequeno registo evita que esteja a resolver problemas numa compilação antiga ou que confunda uma submissão do TestFlight com um lançamento na App Store.

Os revisores precisam de experimentar a aplicação completa

Um revisor não pode avaliar um recurso que não consegue acessar. A lista de verificação de envio da Apple pede acesso total, uma conta de demonstração ativa ou modo de demonstração apropriado, hardware necessário ou recursos de amostra e serviços de backend ativos. Também pede que os desenvolvedores expliquem recursos e compras não óbvios nas notas de revisão. Esses requisitos tornam o acesso um primeiro lugar sensato para investigar. [3]

Teste as credenciais exatas que forneceu, de preferência num dispositivo limpo. Verifique se uma conta precisa de verificação de e-mail, um direito pago, um convite ou uma palavra-passe de uso único. Experimente o percurso de integração sem a sua conta de desenvolvimento. Se uma funcionalidade exigir uma região específica ou um segundo utilizador, explique como o revisor pode reproduzir essa configuração. Não assuma que ele irá inferir o seu fluxo de trabalho pretendido.

Um passo a passo curto e reproduzível é mais útil do que um discurso de vendas. Por exemplo: entre com a conta fornecida, abra a Biblioteca, selecione o projeto de amostra e toque em Exportar. Inclua qualquer limitação esperada e explique por que ela existe. Isso não compra prioridade; reduz a ambiguidade evitável quando alguém chega ao seu envio.

Uma rejeição precisa de uma resposta, não de mais espera

Quando a Apple rejeita uma app, a sua mensagem explica o problema e a diretriz relevante. O App Store Connect permite responder e anexar material de suporte. A Apple também afirma que uma rejeição de metadados pode ser resolvida e reenviada usando a mesma build. Portanto, nem sempre é necessário um novo binário. [4]

Responda à objeção específica. Se o revisor não encontrou uma funcionalidade, forneça os passos de navegação. Se a preocupação for uma captura de ecrã enganosa, corrija a captura. Se discordar, explique o comportamento e forneça evidências em vez de repetir que as aplicações concorrentes o fazem. Separe o que alterou do que está a pedir à Apple para clarificar.

Mantenha um registo simples de problemas: a pergunta do revisor, a sua resposta, o ativo ou build alterado e a próxima ação necessária. Isso torna a correspondência subsequente mais fácil de seguir. Também impede que uma equipa envie independentemente explicações diferentes. A comunicação de revisão é uma conversa de depuração, não um concurso para enviar a resposta mais longa.

O processamento da compilação e o TestFlight são pontos de verificação separados

Um build enviado não está necessariamente pronto para submissão. A referência de status de build da Apple distingue processamento, informações de conformidade ausentes e prontidão para envio. Também distingue os estados Aguardando Revisão e Em Revisão Beta do TestFlight da disponibilidade para testadores internos. Testes beta externos podem exigir Revisão de Aplicativo do TestFlight. [5]

Se a sua beta estiver bloqueada, inspecione o estado da build antes de procurar um problema na fila de revisão da App Store. Para Conformidade em Falta, a Apple instrui os programadores a responder às perguntas de encriptação ou fornecer a documentação relevante. Algumas builds podem declarar uma isenção aplicável através da sua configuração, mas deve responder com precisão em vez de alterar definições apenas para contornar o aviso. [6]

Aprovado nem sempre significa disponível imediatamente

O fluxo de trabalho de publicação da Apple separa a escolha de um build, a definição de disponibilidade, o envio, a resolução de problemas de revisão e a distribuição. Diz que um aplicativo aprovado pode levar até 24 horas para entrar no ar. Você também escolhe se o lançamento é manual, automático ou em fases. Verifique essas configurações antes de descrever uma versão aprovada como “ainda em revisão”. [7]

Para atualizações, um lançamento faseado distribui gradualmente a versão a utilizadores elegíveis com atualizações automáticas ao longo de sete dias. Isso é uma escolha de implementação, não sete dias extra de revisão. Se um cliente ainda vir uma versão mais antiga, confirme primeiro o método de lançamento e a disponibilidade em vez de assumir que o revisor reteve a aprovação. [8]

O Google Play tem uma janela de revisão diferente

Não aplique o tempo de destaque da Apple ao Google Play. O Google diz que as avaliações podem demorar algumas horas ou até sete dias, e mais tempo em casos excecionais. A sua visão geral de publicação também avisa que submeter outra alteração enquanto as alterações estão em revisão pode fazer recuar a app na fila de revisão. Edições pequenas repetidas podem, portanto, prejudicar um lançamento previsível. [9]

A visão geral de publicação da Play Console distingue alterações em revisão de alterações prontas a publicar. Com a publicação gerida ativada, aprovação e publicação são decisões separadas. Olhe para a fila de alterações, não apenas se a nova listagem está visível num telemóvel. Termine o pacote de lançamento pretendido antes de o submeter e evite edições não relacionadas enquanto espera, a menos que algo precise genuinamente de correção.

Um exemplo prático: diagnosticar antes de reenviar

Imagine uma app de acompanhamento de hábitos submetida na segunda-feira de manhã. Na terça-feira à noite, o fundador começa a reconstruí-la porque a aprovação não chegou. Antes de fazer isso, verifica três coisas: se a versão está realmente na fila, se a revisão enviou uma mensagem e se a conta fornecida consegue concluir a integração. Este é um cenário ilustrativo, não um caso medido de cliente AsoTheory.

Se a app estiver simplesmente à espera e o acesso funcionar, uma build de substituição não oferece uma solução demonstrada. Se um revisor reportar uma falha de início de sessão, corrigir o acesso resolve um obstáculo real. Se o estado for Pendente de Lançamento do Programador, a ação correta é lançar, não reenviar. O mesmo tempo decorrido pode exigir três respostas completamente diferentes. É por isso que diagnosticar o estado vem antes de escolher um remédio.

Quando deve contactar a Apple?

Para um atraso inexplicável e invulgarmente longo, use a via de contacto de revisão da Apple com uma linha do tempo concisa e identificadores de submissão. Descreva o estado atual, qualquer correspondência anterior e o que já verificou. Não existe um limite universal de dias na orientação citada que garanta uma escalada. Evite inventar um ou prometer que uma mensagem de suporte fará avançar a sua app.

A revisão acelerada é um pedido separado. A Apple dá exemplos como uma correção de bug crítica ou um lançamento ligado a um evento com o qual está diretamente associado. Explique a circunstância real e o impacto; a impaciência normal de marketing não é a mesma coisa. Um pedido acelerado não deve ser apresentado como um atalho garantido. [1]

Planeie o lançamento em torno da incerteza

Uma nota de lançamento interna útil tem quatro campos: o que está mudando, o que os clientes podem acessar atualmente, quem está monitorando a correspondência de revisão e o que aciona o anúncio. Atribua uma pessoa para ser responsável pelo envio. Combine um cronograma de check-in em vez de todos atualizarem o console a tarde toda. Mantenha as evidências juntas, incluindo mensagens do revisor e a versão exata enviada. Nada disso encurta a fila da Apple, mas evita que a incerteza se transforme em reconstruções desnecessárias ou decisões conflitantes.

Se o seu lançamento adicionar uma nova subscrição ou alterar a integração, prepare respostas de suporte antes de a aprovação chegar. Certifique-se de que as suas ligações de marketing descrevem a versão que as pessoas podem realmente descarregar. Evite anunciar que uma funcionalidade está ativa só porque a sua build foi aceite. Para um primeiro lançamento, tenha uma mensagem de página de destino de reserva pronta. Estas são recomendações operacionais, não requisitos da loja ou promessas sobre a velocidade de revisão: o seu valor é que a sua equipa ainda pode agir sensatamente quando o cronograma está fora do seu controlo.

Mantenha a preparação da revisão numa lista de verificação de lançamento: acesso funcional, notas claras, fluxos de compra testados, ativos precisos, correspondência monitorizada e uma definição de publicação deliberada. Deixe espaço entre a submissão e qualquer data de campanha fixa. Se o timing for essencial, decida antecipadamente o que acontece se a aprovação chegar tarde: pausar o anúncio, manter a versão atual disponível ou comunicar uma janela revista.

Por fim, distinga evidências de histórias. As longas esperas de outros programadores podem ser reais, mas não provam porque é que a sua app está atrasada. Nem a orientação citada da Apple nem a do Google estabelecem uma explicação universal, como apps geradas por IA a causar um atraso. A pergunta útil não é “que rumor explica isto?” mas “em que estado está a minha submissão e há alguma ação que eu possa realmente tomar?”

Relacionado

Blog · Estudos de caso · Free ASO tools · Produtos · Privacidade e termos · AsoTheory