# App Store expedited review: how to request it from Apple

> Apple names two cases: a critical bug in the live version, or a release tied to an event. Here's the process, what to write, and what happens next.

Original page: [App Store expedited review: how to request it from Apple](https://devoria.fr/en/blog/app-store-expedited-review-request)
Author: [Mehdi Azizi](https://devoria.fr/en/mehdi-azizi)
Published: 2026-11-06
Content last revised: 2026-11-06


**Expedited review exists, but Apple keeps it for exceptional circumstances, and it names two: fixing a critical bug in a version that's already live, or releasing a version timed to an event your app is directly tied to.** You submit your version first, explain the urgency in the reviewer Notes, then send the request form. Apple looks at each request and expedites when it can. It's never guaranteed.

My apps, Solys, TradaZen and Nolera, are built with Expo. When a bug comes from the JavaScript code, the fix goes out as an over-the-air update, without going through App Review. So I only need expedited review for a native build, and that's also the first question to ask yourself before requesting it. This guide follows [Apple's help page on expedited review](https://developer.apple.com/help/app-review/after-submitting-for-review/request-expedited-review/), checked on November 6, 2026.

## What Apple names, and what won't fly

Apple talks about exceptional circumstances and asks you to keep requests for real emergencies. Its [App Review page](https://developer.apple.com/distribute/app-review/) gives two examples and what to provide for each. The three rejected rows in the table are my reading of those pages, not a list from Apple.

| Reason                           | Apple's position    | What to provide, or understand                    |
| -------------------------------- | ------------------- | ------------------------------------------------- |
| Critical bug in the live version | Given as an example | Steps to reproduce, current version               |
| Release tied to an event         | Given as an example | The event, its date, how your app is linked to it |
| First release running late       | No, in my opinion   | Nothing makes it urgent in Apple's eyes           |
| Marketing date with no event     | No, in my opinion   | A campaign isn't an event tied to the app         |
| Longer wait than usual           | No, in my opinion   | A normal delay isn't an emergency                 |

**Apple doesn't define the term. In practice, a critical bug is an app that crashes, blocks a core feature or stops people from paying, for real users, in the live version.** A typo on a screen isn't one. And if your app is still in review as an event gets close, Apple says you can also request expediting for that reason.

## The process in three steps

1. **Submit the version in App Store Connect.** Only a submission that's already been sent can be expedited. If features require signing in, add a demo account in the App Review Information section.
2. **Fill in the Notes field when you submit.** For a critical bug, describe the bug you fixed and how to reproduce it on the current version. For an event, give its name, its date and what ties your app to it.
3. **Send the Request an Expedited App Review form**, available from Apple's help page once you're signed in to your developer account. You pick the app and platform, then send.

Apple reviews the request and gets back to you, then you track the submission in App Store Connect. If the request is accepted, the version moves to In Review sooner than the queue would have allowed. If it's declined, the review continues as normal: you lose nothing.

> The Reply to App Review button in App Store Connect isn't for requesting an expedited review. The [App Review contact page](https://developer.apple.com/help/app-review/after-submitting-for-review/contact-app-review/) reserves it for conversations about an ongoing submission; expedited requests and appeals each have their own form.

## What to write: two templates

App Review reads English. Here are the two texts I keep ready, to adapt in the Notes, and in the form if it gives you a free-text field. They fit in five lines because a reviewer should understand the urgency without opening the app.

**Critical bug in the live version:**

> 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.

**Release tied to an event:**

> 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.

These two texts are examples, not requests I actually sent. Two rules for yours. **Verifiable facts**: version, OS, steps, date, link to the event. **Nothing but the urgency**: if your build also includes a new feature, mention it in one sentence, but don't argue for it.

## Before you ask, make sure you need it

Apple asks you to keep it for real emergencies. Three questions, and one trap, before you send the form.

**Can the fix ship without review?** With Expo, an over-the-air update replaces the JavaScript code of already installed apps without a new build. That's the route I use for my fixes. It doesn't cover native code, permissions or native dependencies: for those, you need a build and a review. And its content has to stay within what Apple approved, as the [EAS Update overview](https://docs.expo.dev/eas-update/introduction/) points out: an over-the-air update doesn't change what the app is for. The guide on [phased rollout of an iOS update](https://devoria.fr/en/blog/release-ios-app-update-phased-release) explains what goes through which channel.

**Is the wait actually abnormal?** Apple says it generally reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours. If your version has been [Waiting for Review](https://devoria.fr/en/blog/waiting-for-review-app-store-connect-statuses) for a day, you're within the normal [App Store review time](https://devoria.fr/en/blog/app-store-review-time-how-long). The [submission status page](https://developer.apple.com/help/app-review/after-submitting-for-review/review-status/) also lists what makes a review take longer: a first app with no history, documents to verify, a regulated topic.

**Is the submission complete?** Expediting an incomplete submission speeds up nothing. Apple warns that an incomplete submission delays the review or fails. Demo account, notes, documents: everything needs to be there before the form.

**And above all, don't pull your version to resubmit it.** A removed version leaves the queue and starts over from zero. If Apple asks you a question during review, reply in App Store Connect instead of resubmitting, as explained in the guide on [replying to App Review in the Resolution Center](https://devoria.fr/en/blog/apple-resolution-center-reply-app-review).

## If Apple declines to expedite

You keep your place in the queue: a declined expedite request changes nothing about the review in progress. To avoid ending up here again:

- **Schedule your releases.** For an event, Apple recommends choosing a scheduled release in App Store Connect: the version is reviewed ahead of time and goes live on the date you want. The [version release option](https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/select-an-app-store-version-release-option) is set on the version page, in the App Store Version Release section.
- **Submit early.** A version ready a week before the event leaves time for a normal review, and even for fixing a rejection.
- **Keep a no-review channel for JavaScript.** With Expo, that's what turns a critical bug into a fix that takes a few minutes.

My reviewer note templates, my pre-submission checklist and replies to the most common rejections are all in the [Review Kit](https://devoria.fr/en/kits/app-review). And if you want to know what your submission is missing before you send it, the [free diagnostic](https://devoria.fr/en/diagnostic) tells you and sends you my checklist for avoiding Apple rejections. Every publishing step is in [publishing an app on the App Store](https://devoria.fr/en/expertise/publish-an-app-on-the-app-store).

## Frequently asked questions

### How long does an App Store expedited review take?

Apple gives no timeframe. It says it reviews each request and expedites the review depending on its availability and current demand. An accepted request moves the version to In Review ahead of its turn, with no promised time.

### Can you request an expedited review for a first app?

Nothing forbids it, but Apple keeps expediting for real emergencies and names two examples: a critical bug in a version already live, or a release tied to a dated event. A first release running behind your schedule fits neither, in my opinion.

### How many times can you request an expedited review?

Apple doesn't publish a number. It asks you to keep requests for real emergencies. In my opinion, every request without a real reason makes the next one less credible: save it for a bug that hits your users.

### Should you remove the submission before requesting expediting?

No, it's the opposite. Only a submission that's already been sent can be expedited, and a removed version loses its place in the queue. Submit, fill in the Notes, then send the form.

### Where is the expedited review form?

On Apple's developer website, once you're signed in to your account: the help page on expedited review leads to it through the Request an Expedited App Review link. You pick the app and platform there.

### Does an expedited review guarantee the app will be approved?

No. It only changes your position in the queue. The version has to follow the App Review Guidelines like any other, and a rejection is still possible.

### Can you fix a bug without going through App Review?

With Expo or React Native, an over-the-air update replaces the JavaScript code without a new build or review. Native code, permissions and native dependencies still require a build submitted to Apple.


## Your project

[Review Kit](https://devoria.fr/en/kits/app-review): My App Store review checklist, the Apple rejections I fixed, a Google Play checklist and three Claude Code skills. $55.

[iOS & Android Kit](https://devoria.fr/en/kits/ios): Build your iPhone and Android app with Claude Code: the starter code from my apps, the path all the way to the stores, and every kit. $109.

[Diagnostic: what's between you and your iPhone app](https://devoria.fr/en/diagnostic): 7 questions, 60 seconds: find out what's really stopping you from publishing your iPhone app, get your 4-step path and the kit that fits you.
