How to request an expedited App Store review

You request an expedited review through Apple's developer contact form at developer.apple.com/contact/app-store/?topic=expedite, not through Resolution Center and not from inside App Store Connect. The form asks which app, which version, and why. The reason is the entire request.

Apple grants these at its discretion. There is no entitlement, no published quota, and no published turnaround for a granted request.

Before you file one, check the number Apple does publish. From Apple's App Review page: "On average, 90% of submissions are reviewed in less than 24 hours." If your submission went in this morning, an expedite request may cost you more attention than the wait it saves.

What Apple says it is for

Two circumstances, quoted from the same page:

"You can request the review of your app to be expedited if you face extenuating circumstances, such as fixing a critical bug in your app or releasing your app to coincide with an event you're directly associated with."

Apple then gives specific instructions for each, and these are the closest thing to a scoring rubric you will get.

Critical bug fix:

"When submitting an expedited review to fix a critical bug, include the steps to reproduce the bug on the current version of your app."

Read that carefully. Apple wants reproduction steps for the bug in the version already on the App Store, not a description of your fix. The request is evidence that live users are currently broken.

Event-related app:

"For apps associated with an event, we recommend you plan and schedule the release of your app in App Store Connect. However, if your app is still in review and the launch of your event is quickly approaching, you can request to have your app review expedited. Make sure your request includes the event, date of the event, and your app's association with the event."

Three required facts there: the event, its date, and your association with it. "Directly associated with" is doing work in the earlier sentence. A conference you are sponsoring or a fixture your app covers is an association. A marketing date you chose is not.

What actually gets granted

Apple publishes no approval rate and no worked examples, so anyone giving you a percentage is inventing it. What can be said honestly is that the requests which read as grantable share three properties.

They are verifiable. A crash on launch on the current iOS release, with steps, is checkable in a minute. "Our users are complaining" is not.

They are specific about who is affected and how badly. Number of affected users if you know it, the platform version, whether there is a workaround.

They concern something already live, or a date not set by you. The two circumstances Apple names are both external: a bug that exists now, and an event that exists whether or not you ship.

The requests that do not read as grantable are the ordinary ones: a launch you would like to hit, a marketing email already scheduled, an investor demo, a deadline your own team set last week. None of those are extenuating circumstances, and filing them teaches Apple what your requests are worth.

What it does not do

It does not skip review. An expedited build is still reviewed against the same guidelines. If your build would have been rejected, you have arranged to be rejected sooner.

It does not carry over. Get rejected on an expedited submission and the resubmission is an ordinary submission again, unless you ask again.

It does not fix a queue you have not joined. The request applies to a submission in review. If your version is sitting in Prepare for Submission because the submit never went through, an expedite request does nothing.

It does not speed up processing. If your build is stuck in processing after upload, that is Apple's build pipeline, not App Review, and expediting is the wrong tool.

How to file one

1. Submit the version for review first. Have the version string and build number to hand.
2. Open developer.apple.com/contact/app-store/?topic=expedite and sign in with the Apple Account on your developer membership. Both this form and the appeal form live behind that sign-in.
3. Choose the app and version.
4. Write the reason. Keep it to a short paragraph. Detail below.
5. Send it once, then leave it alone. There is no queue you can see and no acknowledgement to wait for.

What to write

For a critical bug, four sentences is plenty:

"Version 2.3.0, currently live, crashes on launch for all users on iOS 26.1. Steps to reproduce on the live version: install 2.3.0 from the App Store, open the app, it terminates on the splash screen before the first tap. The submitted build 2.3.1 changes one line in the keychain read that causes it. We are seeing this in roughly 40% of sessions since 26.1 shipped."

For an event, name the three facts Apple asks for:

"Our app is the official companion for the Bristol Half Marathon on 14 September 2026. We are the event's technology partner and the app is linked from the organiser's site at [URL]. Version 1.0 is in review and needs to be live by 10 September for participants to collect their race numbers in the app."

Both examples do the same thing: give the reviewer something they can check without asking you a question.

The cost of asking too often

Apple does not publish a quota, so nobody can tell you the number. Its guidance describes expedited review as being for "extenuating circumstances", and one request per launch cycle for ordinary launch pressure is plainly not that.

The practical position is simple enough without a quoted rule. The channel is discretionary. Discretionary channels run on credibility. Keep them for outages and dates you did not choose.

The alternative that actually works

Most launch-day panic is a planning problem wearing an urgency costume, and Apple's own guidance for event apps says so: "we recommend you plan and schedule the release of your app in App Store Connect".

That means setting the version release option to manual, or to "Automatic, no earlier than" a date. Submit well ahead, get approved, and the version sits in Pending Developer Release until you press the button. An unknowable wait becomes a decision you control.

Ship the risky thing early and hold it. Then the expedite request stays available for the week your live app breaks.

FAQ

How long does an expedited review take once granted? Apple publishes no figure. It also does not publish how it tells you the request was granted, which in practice means you may only notice because the state changed.

Can I request expedited review for a first submission? Yes. The event circumstance often applies to first releases. The critical bug circumstance cannot, because it requires a version already live.

Does expedited review work for TestFlight builds? Beta App Review for external TestFlight builds is a separate queue with its own wait.

Is there an expedited review on Google Play? Google publishes no equivalent request form for app review. Play offers managed publishing so you can control when an approved change goes live, which is the same planning move rather than a queue jump.

Will asking twice for the same submission help? No, and there is nothing to suggest a second message does anything except sit next to the first one.

AppSubmit will not make Apple faster, and no tool can. What it does is show you the version state the moment it changes, so you know whether you are waiting on the queue, on processing, or on a submission that never actually left your account. App Store Connect shows the same state if you go and look.