Por que a revisão do app está demorando tanto?

Uma revisão lenta não significa automaticamente que seu app 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.

Você enviou o build, verificou as capturas de tela e planejou seu lançamento. Então nada acontece. O App Store Connect ainda diz Aguardando Revisão, ou o Play Console mantém suas alterações em revisão. Enquanto isso, cada dia de incerteza dificulta a coordenação de marketing, suporte ao cliente e um anúncio de lançamento.

A parte frustrante é que um atraso tem várias explicações possíveis. Sua submissão pode simplesmente estar esperando sua vez. Um avaliador pode precisar de informações. Sua compilação pode nem ter chegado à revisão. Ou a revisão pode já ter terminado, com a publicação esperando por você. Este guia explica como distinguir essas situações. Ele se concentra 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 levar a revisão do 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 app 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 planejamento, não um compromisso de lançamento. Uma submissão que leva mais de um dia não é, por si só, evidência de rejeição ou conta quebrada. Da mesma forma, uma média não deve persuadi-lo a ignorar uma mensagem acionável. O status e a correspondência do avaliador importam mais do que comparações com a aprovação mais rápida de outro desenvolvedor.

Primeiro, identifique onde está realmente o atraso

Leia o status preciso em vez de traduzir cada indicador amarelo para "A Apple está revisando meu app." Waiting for Review significa que o envio está na fila; In Review significa que a revisão começou. Pending Developer Release significa que o app foi aceito, mas ainda precisa da sua ação de liberação. Waiting for Export Compliance é um processo diferente. Um item aceito também pode permanecer não publicado se outro item em seu envio foi rejeitado. [2]

Verifique a versão do app e o envio juntos, não apenas a compilação carregada. Uma captura de tela da lista de compilações pode contar uma história diferente da página de envio. Anote a versão, o número da compilação, o horário do envio e o status atual. Esse pequeno registro evita que você solucione problemas em uma compilação antiga ou confunda um envio do TestFlight com um lançamento na App Store.

Os avaliadores precisam experimentar o aplicativo completo

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 demo ativa ou modo demo 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 você forneceu, de preferência em um dispositivo limpo. Verifique se uma conta precisa de verificação de e-mail, um direito pago, um convite ou uma senha de uso único. Tente o caminho de integração sem sua conta de desenvolvimento. Se um recurso exigir uma região específica ou um segundo usuário, explique como o avaliador pode reproduzir essa configuração. Não presuma que eles 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 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 um app, 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 o mesmo build. Portanto, um binário novo nem sempre é necessário. [4]

Responda à objeção específica. Se o avaliador não encontrou um recurso, forneça os passos de navegação. Se a preocupação for uma captura de tela enganosa, corrija a captura. Se você discordar, explique o comportamento e forneça evidências em vez de repetir que aplicativos concorrentes fazem isso. Separe o que você mudou do que está pedindo à Apple para esclarecer.

Mantenha um registro simples de problemas: a pergunta do revisor, 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 acompanhar. Também impede que uma equipe envie independentemente explicações diferentes. A comunicação de revisão é uma conversa de depuração, não uma competição 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 App do TestFlight. [5]

Se seu beta está travado, inspecione o status do build antes de procurar um problema na fila de revisão da App Store. Para Missing Compliance, a Apple instrui os desenvolvedores a responder às perguntas de criptografia ou fornecer a documentação relevante. Alguns builds podem declarar uma isenção aplicável por meio de sua configuração, mas você deve responder com precisão em vez de alterar configurações apenas para contornar o prompt. [6]

Aprovado nem sempre significa imediatamente disponível

O fluxo de trabalho de publicação da Apple separa escolher um build, definir disponibilidade, enviar, resolver problemas de revisão e distribuição. Diz que um app 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 em fases distribui gradualmente a versão para usuários elegíveis com atualizações automáticas ao longo de sete dias. Essa é uma escolha de lançamento, não sete dias extras de revisão. Se um cliente ainda vê uma versão antiga, primeiro confirme o método de lançamento e a disponibilidade em vez de presumir que o revisor reteve a aprovação. [8]

O Google Play tem uma janela de revisão diferente

Não aplique o tempo de manchete da Apple ao Google Play. O Google diz que as avaliações podem levar algumas horas ou até sete dias, e mais em casos excepcionais. Sua visão geral de publicação também alerta que enviar outra alteração enquanto as alterações estão em análise pode empurrar o app de volta na fila de análise. Edições pequenas repetidas podem, portanto, prejudicar um lançamento previsível. [9]

A visão geral de publicação do Play Console distingue mudanças em revisão de mudanças prontas para publicar. Com a publicação gerenciada ativada, aprovação e publicação são decisões separadas. Olhe para a fila de mudanças, não apenas se a nova listagem está visível em um telefone. Termine o pacote de lançamento pretendido antes de enviá-lo e evite edições não relacionadas enquanto espera, a menos que algo realmente precise ser corrigido.

Um exemplo prático: diagnosticar antes de reenviar

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

Se o app está simplesmente aguardando e o acesso funciona, um build de substituição não oferece solução demonstrada. Se um revisor relata falha de login, corrigir o acesso aborda um obstáculo real. Se o status é Pending Developer Release, a ação correta é liberar, não reenviar. O mesmo tempo decorrido pode exigir três respostas totalmente diferentes. É por isso que diagnosticar o estado vem antes de escolher um remédio.

Quando você deve contatar a Apple?

Para um atraso inexplicável e incomumente longo, use a rota de contato de revisão da Apple com uma linha do tempo concisa e identificadores de envio. Descreva o estado atual, qualquer correspondência anterior e o que você já verificou. Não há um limite universal de dias na orientação citada que garanta escalonamento. Evite inventar um ou prometer que uma mensagem de suporte fará seu app avançar.

A revisão acelerada é uma solicitação separada. A Apple dá exemplos como uma correção crítica de bug ou um lançamento vinculado a um evento com o qual você está diretamente associado. Explique a circunstância real e o impacto; impaciência comum de marketing não é a mesma coisa. Uma solicitação acelerada não deve ser apresentada como um atalho garantido. [1]

Planeje 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 dispara 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 seu lançamento adiciona uma nova assinatura ou muda a integração, prepare respostas de suporte antes da aprovação chegar. Certifique-se de que seus links de marketing descrevam a versão que as pessoas realmente podem baixar. Evite anunciar que um recurso está no ar só porque seu build foi aceito. Para um primeiro lançamento, tenha uma mensagem de página de destino de contingência pronta. Estas são recomendações operacionais, não requisitos da loja ou promessas sobre a velocidade de revisão: seu valor é que sua equipe ainda pode agir com sensatez quando o cronograma está fora de seu controle.

Mantenha a preparação para revisão em uma lista de verificação de lançamento: acesso funcional, notas claras, fluxos de compra testados, ativos precisos, correspondência monitorada e uma configuração de publicação deliberada. Deixe espaço entre o envio e qualquer data de campanha fixa. Se o tempo for essencial, decida com antecedência o que acontece se a aprovação atrasar: pausar o anúncio, manter a versão atual disponível ou comunicar uma janela revisada.

Por fim, distinga evidências de histórias. As longas esperas de outros desenvolvedores podem ser reais, mas não provam por que seu app está atrasado. Nem a orientação citada da Apple nem do Google estabelece uma explicação universal, como apps gerados por IA causando um acúmulo. A pergunta útil não é “que rumor explica isso?” e sim “em que estado está meu envio e há alguma ação que eu possa realmente tomar?”

Relacionado

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