We ship small iOS apps, and most releases go through Apple's review queue the ordinary way: submit, wait, ship. Expedited review exists for the narrow slice of cases where the wait itself causes harm, and Apple grants one when the request is honest and the build behind it is actually ready to go.
When Apple says yes
The clearest case is a critical bug in a version that's already live: a crash on launch, a broken purchase flow, a feature that silently corrupts a user's data. If real people are hitting it right now and you have a fix built and sitting in the queue, that's exactly what this process is for. A time-sensitive event is the second case — a feature tied to a specific date that's already been announced or is otherwise fixed on the calendar, where shipping a day late defeats the point of shipping at all. A legal or safety issue you can't leave in production for another week is the third.
What doesn't qualify is anything that only feels urgent to us. An ordinary launch we're excited about isn't urgent to Apple. A marketing date we set ourselves isn't urgent to Apple. Neither is plain impatience with the queue, however justified it feels after a long build cycle. The line Apple draws is between a deadline that exists out in the world and a deadline we invented, and it doesn't hesitate to decline the second kind.
Asking well
The request goes through the expedited review form at developer.apple.com, not email or a support ticket. The form itself is short; the paragraph you write is the entire pitch, so we treat it that way — one factual paragraph, nothing more. Name the app and its Apple ID. State plainly what broke and who it's hurting, with a real number if we have one: "affecting roughly a third of new sign-ups" carries more weight than "many users." Confirm the fixed build is already submitted and sitting in the queue, waiting. Then ask directly for an expedited review. We don't pad the request with backstory and we don't apologize for asking — whoever reads it is working through a stack of these and wants the facts, not the tone.
Submitting the form gives no confirmation beyond the fact that it went through: no ticket number, no queue position, nothing to refresh while you wait. When a request is granted, review typically happens quickly — often within about a day, in our experience, though that's a pattern we've observed rather than anything Apple commits to in writing. When nothing happens, there's no follow-up notice either; the queue just continues at its normal pace. The right response to silence is patience, not a second request stacked on top of the first.
A favor, not a lane
Expedited review is a courtesy a person at Apple extends, not a lane we're entitled to use whenever the queue feels slow. We ask a handful of times a year at most, and only for the cases above — most "should we expedite this" conversations end with the answer being that the normal queue is fine. Studios that lean on it for every release tend to find their requests quietly ignored after a while; the courtesy stays available to teams that use it rarely and for real reasons, not to whoever asks most often.
The better fix, most of the time, is not needing to ask at all. A steady release cadence with real testing before submission catches the bugs that would otherwise turn into emergencies. Phased release — rolling a new version out to a small percentage of users before it reaches everyone — turns a bad build into a problem affecting a few hundred people instead of the whole install base, which buys enough time to pull it or patch it without ever opening the expedite form. The calmer way to ship software is the one where you rarely need the emergency lane, because the ordinary lane was built carefully enough to catch the emergency before it happened.