On this page (7 sections)
What qualifies — and what does not
| Likely to qualify | Unlikely to qualify |
|---|---|
| A critical bug in the live version — crash on launch, login broken, data loss, payments failing — with steps to reproduce on the current App Store build | A normal feature release, a marketing deadline, or an internal promise to a client |
| A release that must coincide with an event you are directly associated with (conference, product launch, broadcast), with the event date and your association stated | A first submission that is simply taking longer than expected |
| A security fix affecting users now | “Our competitor launched” or “our investors are waiting” |
| A regression introduced by your last update that you can name precisely | Repeated requests for every release — Apple notices |
How to request it
- Submit the build for review first — an expedited request is about a submission that exists, with a version number Apple can find.
- Open Contact App Review (Apple Developer sign-in required) and choose the expedited-review topic; it is also reachable from App Store Connect.
- Identify the app (name, Apple ID / bundle ID, version) and pick the reason: critical bug fix or event.
- Explain in a few sentences what is broken, who is affected, and — for bugs — “the steps to reproduce the bug on the current version of your app”. For events: the event, its date and your association with it.
- Submit once. Apple replies by email; if the request is granted the submission moves ahead in the queue. If it is declined, the normal review continues — do not resubmit the same request.
Source: Apple Developer, App Review and Contact App Review — request an expedited review (verified 22 September 2026).
What a credible request looks like
- Specific: “Version 4.2.0 (build 418), live since 12 Sep, crashes on launch for users on iOS 26.0 with a non-English locale. Reproduce: install from the App Store, set device language to German, open the app.”
- Measured: “Crashlytics shows 31 % of daily sessions affected since the release.” Real numbers from your own tooling, never invented.
- Scoped: “The fix in 4.2.1 changes only the locale-formatting code; no new features.” A bug-fix build that also adds a paywall is not a bug-fix build.
- Short and polite. App Review reads thousands of these. Three paragraphs, no pleading, no threats.
The build has to deserve it
An expedited review is still a full review. If the critical-fix build gets rejected — crash on the reviewer’s device, missing demo account, metadata mismatch — you have lost the time you were trying to save. Test the fix on a clean install, make sure reviewer access still works, and keep the release notes honest. If the rejection does come, read the message before you react: see Guideline 2.1 for completeness rejections.
Expedited review is not an appeal
If the version was rejected, a faster queue does not help — the rejection reason has to be resolved or contested. Whether to fix, reply or appeal is a different decision, covered on Should you appeal an App Store rejection?. Expedited review is for a submission that is waiting, not one that was refused.
Meanwhile: reduce the damage
- Use phased release and manual release for future versions so a bad build can be halted before it reaches everyone.
- Keep a remote kill switch or feature flag for risky code paths so a fix can be a configuration change instead of a submission.
- Answer App Review promptly if they ask a question — an unanswered message pauses the clock.
- Check App Store Connect statuses rather than refreshing the page: Waiting for Review, In Review, Pending Developer Release each mean something specific (App Store Connect Help, App and submission statuses).
What we do
- Check whether your case matches Apple’s two published circumstances and tell you honestly if it does not.
- Review the fix build for the things that get expedited builds rejected: crashes on clean install, reviewer access, entitlements, metadata.
- If the bug itself is not yet fixed — a crash you cannot reproduce, a backend issue, a signing or SDK problem — our engineers work on the fix so the request has substance.
- Draft the request text with you, from your own data.
Checklist
- The build is submitted and identifiable by version and build number
- Reason is one of Apple’s two: critical bug (with reproduction steps) or event (with date and association)
- Impact stated from your own metrics; scope of the change is limited to the fix
- Fix verified on a clean install; reviewer credentials still valid
- One request, then wait for Apple’s email