Apple's expedited review: how it works, how to ask, and when to burn it
Expedited review is a favor Apple grants, not a service you're owed. How the request actually works, what makes a good one, and why needing it regularly is a signal about your release architecture.
Somewhere in your future is a night where a critical bug is live, the fix is ready, and the build is sitting in "Waiting for Review." Apple has a mechanism for exactly this — the expedited review request. Apple describes it for extenuating circumstances; it is not a guaranteed incident-response lane. Used sparingly and with a clear explanation, it gives your submission the best case for extra attention.
The mechanics
You request an expedite through Apple's App Review page, signed in with your developer account. Apple asks for your circumstances; for a critical bug, it specifically asks you to include reproduction steps for the current version. Apple does not publish a response-time or approval guarantee, so make the request early and keep a normal incident plan in motion.
What qualifies, in practice
- A critical bug fix — crashes on launch, broken checkout, data loss. The stronger and more specific your evidence, the better.
- A time-sensitive event — your app supports a live event with an immovable date. Ask days ahead, not hours.
- Legal or safety issues — a compliance deadline or a security fix that can't wait.
"We'd really like to launch Tuesday" is not one of Apple's stated examples. Put the actual user impact and fixed deadline on the page instead.
Writing a request that gets granted
Make triage easy. Concretely: state the user impact in the first sentence ("crash on launch for users on iOS 26.2, affecting roughly 30% of sessions"), quantify it if you can, name the fix ("resolves a null dereference in the payment confirmation screen"), and include the requested reproduction steps. Keep it factual and concise.
The unwritten rule: it's a budget
Apple frames expedites around extenuating circumstances, not release cadence. Treat one as an exception, not a routine deployment mechanism. Which raises the useful question:what does it say about your release setup if you need one every month?
Needing expedites often is an architecture smell
An expedite can help with a native emergency, but it is not an incident SLA. If an emergency is a compatible JavaScript-level fix, an over-the-air channel can shorten the delivery path after your own review and rollout controls. It is not a workaround for store policy: see the policy guardrails. A healthy release setup uses OTA with staged rollouts for JS fixes, the normal review queue for native changes, and the expedite lane for the rare native emergency — a crash in a native module, a broken third-party SDK — where it's the only fast path that exists. Keep the favor for the day only the favor will do.