# Revisão acelerada na App Store: como pedir à Apple > A Apple cita dois casos: um bug crítico na versão publicada ou um lançamento ligado a um evento. Veja o passo a passo, o que escrever e o que acontece depois. Página original: [Revisão acelerada na App Store: como pedir à Apple](https://devoria.fr/pt-br/blog/revisao-acelerada-app-store-como-pedir) Autor: [Mehdi Azizi](https://devoria.fr/pt-br/mehdi-azizi) Publicação: 2026-11-06 Última revisão do conteúdo: 2026-11-06 **A revisão acelerada existe, mas a Apple a reserva para circunstâncias excepcionais e cita duas: corrigir um bug crítico numa versão já publicada ou lançar uma versão alinhada a um evento ao qual o seu app está diretamente ligado.** Primeiro você envia a versão, explica a urgência nas Notes para o revisor e depois manda o formulário de solicitação. A Apple analisa cada pedido e acelera conforme a disponibilidade dela: nunca é garantido. Meus apps, Solys, TradaZen e Nolera, são feitos com Expo. Quando um bug vem do código JavaScript, a correção sai como atualização remota, sem passar pelo App Review. Então a revisão acelerada só me serve para um build nativo, e essa também é a primeira pergunta que você deve se fazer antes de pedir. Este guia segue a [página de ajuda da Apple sobre revisão acelerada](https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review/), relida em 6 de novembro de 2026. ## O que a Apple cita, e o que não passa A Apple fala em circunstâncias excepcionais e pede que os pedidos fiquem para urgências reais. A [página do App Review](https://developer.apple.com/distribute/app-review/) dá dois exemplos e o que fornecer em cada um. As três linhas recusadas da tabela são a minha leitura dessas páginas, não uma lista da Apple. | Motivo | Para a Apple | O que fornecer, ou entender | | ------------------------------- | --------------------- | ------------------------------------------------- | | Bug crítico na versão publicada | Citado como exemplo | Passos para reproduzir, versão atual | | Lançamento ligado a um evento | Citado como exemplo | O evento, a data, a ligação entre o seu app e ele | | Primeira publicação atrasada | Não, na minha opinião | Nada a torna urgente aos olhos da Apple | | Data de marketing sem evento | Não, na minha opinião | Uma campanha não é um evento ligado ao app | | Espera maior do que o normal | Não, na minha opinião | Um prazo normal não é urgência | **A Apple não define o termo. Na prática, um bug crítico é um app que trava, que bloqueia uma função essencial ou que impede o pagamento, para usuários reais, na versão publicada.** Um erro de digitação numa tela não é. E se o seu app ainda estiver em revisão às vésperas de um evento, a Apple diz que você também pode pedir a aceleração por esse motivo. ## O processo em três passos 1. **Envie a versão no App Store Connect.** Só uma submissão já enviada pode ser acelerada. Se alguma função exige login, informe uma conta de demonstração na seção App Review Information. 2. **Preencha o campo Notes na hora de enviar.** Para um bug crítico, descreva o bug corrigido e como reproduzi-lo na versão atual. Para um evento, informe o nome, a data e o que liga o seu app a ele. 3. **Envie o formulário Request an Expedited App Review**, acessível pela página de ajuda da Apple depois de entrar na sua conta de desenvolvedor. Ali você escolhe o app e a plataforma, e envia. A Apple analisa o pedido e responde, e você acompanha a submissão no App Store Connect. Se o pedido for aceito, a versão passa para In Review antes do que a fila permitiria. Se for recusado, a revisão segue o curso normal: você não perde nada. > O botão Reply to App Review, no App Store Connect, não serve para pedir revisão acelerada. A [página de contato do App Review](https://developer.apple.com/help/app-review/after-submitting-for-review/contact-app-review/) o reserva para conversas sobre uma submissão em andamento; o pedido de aceleração e a apelação têm cada um o seu formulário. ## O que escrever: dois modelos O App Review lê em inglês. Aqui estão os dois textos que deixo prontos, para adaptar nas Notes, e no formulário se ele tiver um campo livre. Eles cabem em cinco linhas porque o revisor precisa entender a urgência sem abrir o app. **Bug crítico na versão publicada:** > Version 2.0.3, currently live, crashes at launch for users who enabled notifications on iOS 26.1. Steps to reproduce: install 2.0.3, allow notifications, force quit, relaunch. The app closes immediately. Version 2.0.4 fixes the crash (notification permission is now read after the first screen loads). No other change in this build. **Lançamento ligado a um evento:** > This version adds the official schedule and live results for the Nantes Trail Festival on June 5, 2027. Our app is the event's official companion app (see the link to the organizer's page in the App Review Information section). Attendees need the update before the start on June 5 at 8:00 AM CEST. Esses dois textos são exemplos, não pedidos que eu enviei. Duas regras para os seus. **Fatos verificáveis**: versão, sistema, passos, data, ligação com o evento. **Nada além da urgência**: se o seu build também traz uma função nova, diga isso em uma frase, mas não a defenda. ## Antes de pedir, confira se você precisa A Apple pede que ela fique para urgências reais. Três perguntas, e uma armadilha, antes de enviar o formulário. **A correção passa sem revisão?** Com Expo, uma atualização remota substitui o código JavaScript dos apps já instalados sem um novo build. É o caminho que uso para minhas correções. Ela não cobre código nativo, permissões nem dependências nativas: para isso, precisa de build e revisão. E o conteúdo dela deve ficar dentro do que a Apple aprovou, como lembra a [apresentação do EAS Update](https://docs.expo.dev/eas-update/introduction/): uma atualização remota não muda o propósito do app. O guia sobre [lançamento gradual de uma atualização iOS](https://devoria.fr/pt-br/blog/publicar-atualizacao-app-ios-lancamento-gradual) detalha o que passa por onde. **A espera é anormal?** A Apple diz que, em geral, analisa pelo menos 50% das submissões em menos de 24 horas e 90% em menos de 48 horas. Se a sua versão está [aguardando revisão](https://devoria.fr/pt-br/blog/waiting-for-review-app-store-connect-status) há um dia, você está dentro do normal do [prazo de aprovação da App Store](https://devoria.fr/pt-br/blog/prazo-aprovacao-app-store-quanto-tempo). A [página de acompanhamento de uma submissão](https://developer.apple.com/help/app-review/after-submitting-for-review/review-status/) também lembra o que alonga uma revisão: primeiro app sem histórico, documentos a verificar, tema regulamentado. **A submissão está completa?** Uma revisão acelerada numa submissão incompleta não acelera nada. A Apple avisa que uma submissão incompleta atrasa a revisão ou é reprovada. Conta de demonstração, notas, documentos: tudo precisa estar lá antes do formulário. **E, acima de tudo, não retire a sua versão para reenviar.** Uma versão retirada sai da fila e recomeça do zero. Se a Apple fizer uma pergunta durante a revisão, responda no App Store Connect em vez de reenviar, como explica o guia sobre [responder ao App Review no Resolution Center](https://devoria.fr/pt-br/blog/resolution-center-apple-responder-rejeicao-app-review). ## Se a Apple recusar a aceleração Você mantém o seu lugar na fila: uma recusa de aceleração não muda nada na revisão em andamento. Para não passar por isso de novo: - **Agende seus lançamentos.** Para um evento, a Apple recomenda escolher a publicação agendada no App Store Connect: a versão é revisada com antecedência e sai na data desejada. A [opção de lançamento de uma versão](https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/select-an-app-store-version-release-option) fica na página da versão, na seção App Store Version Release. - **Envie cedo.** Uma versão pronta uma semana antes do evento dá tempo para uma revisão normal, e até para corrigir uma reprovação. - **Mantenha um canal sem revisão para o JavaScript.** Com Expo, é isso que transforma um bug crítico numa correção de poucos minutos. Meus modelos de notas para o revisor, meu checklist antes do envio e as respostas às reprovações mais comuns estão reunidos no [Review Kit](https://devoria.fr/pt-br/kits/app-review). E se você quer saber o que falta na sua submissão antes de enviar, o [diagnóstico gratuito](https://devoria.fr/pt-br/diagnostic) mostra isso e te manda meu checklist contra reprovações da Apple. Todas as etapas da publicação estão em [publicar um aplicativo na App Store](https://devoria.fr/pt-br/expertise/publicar-app-na-app-store). ## Perguntas frequentes ### Quanto tempo leva uma revisão acelerada na App Store? A Apple não dá prazo nenhum. Ela diz que analisa cada pedido e acelera a revisão conforme a disponibilidade e a demanda do momento. Um pedido aceito faz a versão passar para In Review antes da vez dela, sem promessa de horário. ### Dá para pedir revisão acelerada para um primeiro app? Nada impede, mas a Apple reserva a aceleração para urgências reais e cita dois exemplos: um bug crítico numa versão já publicada ou um lançamento ligado a um evento com data. Uma primeira publicação atrasada em relação ao seu cronograma não se encaixa, na minha opinião, em nenhum dos dois. ### Quantas vezes dá para pedir revisão acelerada? A Apple não publica um número. Ela pede que os pedidos fiquem para urgências reais. Na minha opinião, cada pedido sem motivo real deixa o próximo menos crível: guarde para um bug que afeta seus usuários. ### Preciso retirar a submissão antes de pedir a aceleração? Não, é o contrário. Só uma submissão já enviada pode ser acelerada, e uma versão retirada perde o lugar na fila. Envie, preencha as Notes e depois mande o formulário. ### Onde fica o formulário de revisão acelerada? No site de desenvolvedores da Apple, depois de entrar na sua conta: a página de ajuda sobre revisão acelerada leva até ele pelo link Request an Expedited App Review. Ali você escolhe o app e a plataforma. ### Uma revisão acelerada garante que o app será aprovado? Não. Ela só muda a posição na fila. A versão precisa seguir as App Review Guidelines como qualquer outra, e a reprovação continua possível. ### Dá para corrigir um bug sem passar pelo App Review? Com Expo ou React Native, uma atualização remota substitui o código JavaScript sem novo build nem revisão. Código nativo, permissões e dependências nativas sempre exigem um build enviado à Apple. ## Seu projeto [Review Kit](https://devoria.fr/pt-br/kits/app-review): Meu checklist de revisão da App Store, as recusas da Apple que corrigi, o checklist do Google Play e três skills do Claude Code. R$ 289. [iOS & Android Kit](https://devoria.fr/pt-br/kits/ios): Crie seu app para iPhone e Android com o Claude Code: o código inicial dos meus apps, o caminho até as lojas e todos os kits. R$ 589. [Diagnóstico: o que te separa do seu app de iPhone](https://devoria.fr/pt-br/diagnostic): 7 perguntas, 60 segundos: descubra o que realmente te impede de publicar seu app de iPhone, seu caminho em 4 etapas e o kit certo para você.