Se o seu aplicativo da Apple parece travado na revisão durante o fim de semana, na maioria das vezes isso é normal e não exige ação. A App Review da Apple funciona todos os dias, inclusive aos sábados e domingos, e a Apple afirma que, em média, 90% das submissões são revisadas em menos de 24 horas, embora algumas demorem mais. Por isso, se o estado ainda está dentro de alguns dias, o certo é aguardar em vez de cancelar ou reenviar, porque reenviar um novo build coloca o app de volta no fim da fila.
Resposta rápida
Um app parado na revisão no fim de semana costuma estar apenas na fila normal, não travado de fato. Segundo a Apple, em média 90% das submissões são revisadas em menos de 24 horas, e a revisão ocorre todos os dias. Se ainda está dentro de poucos dias, aguarde; não cancele nem reenvie, pois isso reinicia sua posição na fila. Só contate a Apple se o atraso for bem acima do normal.
O que significa o estado
Antes de agir, vale entender o que o painel está mostrando. Os dois estados mais comuns nesse momento são Aguardando revisão, quando o app entrou na fila mas ainda não começou a ser avaliado, e Em revisão, quando um avaliador já está analisando o build. Ambos são parte do fluxo normal, e ver o app parado em um deles por algumas horas ou por um dia não indica problema.
O que costuma assustar é a sensação de que nada se move, especialmente num fim de semana. Mas o estado não avança em tempo real: ele muda quando a etapa correspondente termina. Um app pode ficar em Aguardando revisão por um tempo e depois passar direto para aprovado. Por isso, o estado parado não significa que algo deu errado, e sim que a etapa ainda está em andamento. A leitura correta é olhar há quanto tempo ele está ali, não o fato de estar parado.
A Apple revê aos fins de semana?
Sim. A App Review da Apple opera todos os dias, incluindo fins de semana e feriados, e é por isso que a média de menos de 24 horas se sustenta ao longo da semana inteira. Um app submetido numa sexta à noite pode perfeitamente ser aprovado no sábado ou no domingo. Portanto, a ideia de que a revisão para no fim de semana e só volta na segunda não corresponde ao funcionamento normal da Apple.
Dito isso, o volume e a variação existem. Em períodos de pico, como semanas próximas a grandes lançamentos ou datas de festas, os tempos podem se alongar para alguns dias, e isso vale tanto em dias úteis quanto no fim de semana. Então a resposta honesta é que a revisão acontece no fim de semana, mas o tempo exato varia e a Apple não garante um prazo fixo. O fim de semana em si não é o motivo do atraso; a fila e o volume são.
Quanto tempo é normal
A referência mais confiável é a própria Apple: em média, 90% das submissões saem em menos de 24 horas. Na prática, muitos desenvolvedores veem tempos entre algumas horas e um a três dias, e submissões de apps novos tendem a demorar mais do que atualizações. Ficar de um a três dias em revisão, mesmo cruzando um fim de semana, está dentro da faixa normal e não é motivo para agir.
O que sai do normal é um estado que não se move por vários dias seguidos, tipicamente acima de uma semana, sem qualquer mudança nem mensagem no Resolution Center. Aí passa a fazer sentido investigar e, se necessário, contatar a Apple. A distinção prática é simples: dentro de poucos dias, é fila; muito além disso e sem comunicação, pode ser algo preso que vale escalar. Como a Apple não promete um prazo fixo, use essas faixas como orientação, não como garantia.
Esperar ou reenviar?
Esta é a decisão que mais gera erro. Se o app está em Aguardando revisão ou Em revisão e ainda dentro de poucos dias, o certo é esperar. Reenviar um novo build não acelera a análise; pelo contrário, ele substitui o build anterior e volta para o fim da fila, o que costuma atrasar em vez de ajudar. Então, sem um motivo concreto, reenviar durante o fim de semana normalmente piora a situação.
Reenviar só faz sentido quando você realmente precisa corrigir algo no build, por exemplo depois de uma rejeição no Resolution Center ou ao identificar um erro grave que iria falhar de qualquer forma. Nesse caso, o novo envio reinicia a revisão daquele build, o que é esperado. Fora isso, cancelar e reenviar apenas para tentar destravar é contraproducente. A regra é: se o objetivo é só sair do estado parado, não reenvie; se há uma correção real a fazer, reenvie ciente de que a fila recomeça.
Como desbloquear e escalar
Quando o atraso passa do normal, há passos concretos. Primeiro, confira o Resolution Center no App Store Connect: se a Apple pediu informações ou apontou um problema, o app fica efetivamente parado até você responder, e essa é a causa mais comum de um app que não anda. Responder ali costuma ser o que realmente destrava. Segundo, confirme que não há pendências óbvias, como acordos ou informações de conformidade em aberto.
Se, mesmo assim, o app estiver muito além do prazo normal, use o formulário de contato da Apple para desenvolvedores e descreva o caso. Para situações urgentes e legítimas, como corrigir um bug crítico ou lançar junto a um evento ao qual você está diretamente associado, é possível solicitar uma revisão expedita, que a Apple avalia caso a caso e não garante. Não peça expedição só porque é fim de semana; reserve isso para urgências reais, já que pedidos em excesso tendem a ser aprovados com menos frequência.
Estados e o que fazer
Mapear cada estado à ação certa evita reenvios desnecessários. A tabela abaixo resume.
| Estado | O que significa | O que fazer |
|---|---|---|
| Aguardando revisão | Na fila, ainda não avaliado | Aguardar dentro de poucos dias |
| Em revisão | Avaliador analisando o build | Aguardar, não reenviar |
| Metadados rejeitados | Ajuste pedido nos metadados | Responder no Resolution Center |
| Rejeitado | Problema no build ou nas regras | Corrigir e reenviar o build |
| Parado acima de uma semana | Fora da faixa normal | Checar Resolution Center e contatar |
Leia a última linha como o gatilho de escalada: só aí contatar a Apple faz sentido.
Checklist de desbloqueio
Antes de contatar o suporte, percorra estes pontos. A lista abaixo cobre o essencial.
| Verificação | Ação | Feito? |
|---|---|---|
| Tempo real parado | Contar os dias, não só a sensação | [ ] |
| Resolution Center | Ver e responder mensagens da Apple | [ ] |
| Acordos e conformidade | Confirmar que nada está pendente | [ ] |
| Necessidade de reenvio | Reenviar só se houver correção real | [ ] |
| Urgência legítima | Pedir revisão expedita apenas se justificado | [ ] |
| Contato com a Apple | Usar o formulário se muito acima do normal | [ ] |
O item mais esquecido é o segundo: uma mensagem não respondida no Resolution Center trava o app até você agir.
Onde entra a segurança
Nada disso acelera a revisão em si, que é controlada pela Apple, mas preparar bem a submissão reduz o risco de rejeições que causam justamente esses atrasos.
Um scanner como o PTKD.com analisa o pacote do seu app iOS ou Android e sinaliza problemas de segurança, como chaves expostas ou permissões excessivas, antes do envio, mapeando os achados para o OWASP MASVS. Para ser claro quanto ao limite: o PTKD não influencia o tempo de fila nem o estado da revisão, que dependem só da Apple. O que ele evita é a categoria de rejeição por segurança que faz o app voltar para o começo do processo, e é por isso que rodar uma verificação antes de submeter ajuda a não somar atrasos evitáveis a uma fila que já é incerta.
O que reter
- Um app da Apple parado na revisão no fim de semana costuma estar apenas na fila normal, já que a App Review funciona todos os dias, inclusive sábados e domingos.
- A Apple afirma que, em média, 90% das submissões são revisadas em menos de 24 horas, mas não garante prazo fixo, e alguns casos levam de um a três dias ou mais em picos.
- Dentro de poucos dias, aguarde; não cancele nem reenvie só para destravar, porque um novo build volta para o fim da fila.
- Reenvie apenas quando houver uma correção real; verifique o Resolution Center, pois uma mensagem não respondida é a causa mais comum de um app que não anda.
- Escale só quando o atraso for bem acima do normal, use o formulário de contato da Apple e reserve a revisão expedita para urgências legítimas; uma verificação com o PTKD.com antes do envio evita rejeições de segurança que geram novos atrasos.
