TL;DR. Expedited review is a request you submit through Apple’s Contact Us form, not a button inside a version’s status page. Apple’s own App Review page documents exactly two qualifying scenarios: a critical bug fix (with steps to reproduce it on the current live version) and an event-related release (with the event name, date, and how your app is tied to it). Apple doesn’t publish a numeric cap on how often you can ask, but it does track your history — and approval speeds up the review, not the release. If your version is set to manual or scheduled release, an expedited approval still sits waiting for you or the clock to release it.

What actually qualifies for expedited review?

Apple’s App Review page lists two circumstances: fixing a critical bug in a live app, or releasing a version to coincide with an event you’re directly associated with. For a bug fix, Apple asks you to include steps to reproduce the issue on the current version already on the Store. For an event, it asks for the event name, its date, and your app’s connection to it — a routine feature update or a missed self-imposed deadline isn’t either of these.

That’s a narrower bar than “I want this update live faster.” A keyword rewrite, a new set of screenshots, or a subtitle change riding along in the same build doesn’t qualify on its own — but if that same version also happens to fix a crash, the crash is what you cite in the request, not the metadata.

How do you actually submit the request?

There’s no expedite button on a version’s page in App Store Connect. You request it through Apple’s developer Contact Us form (developer.apple.com/contact/app-store/), which requires signing in with a developer account that has access to the app in question, then choosing the App Review topic and the expedite option. You’ll need the app name, the pending submission you want expedited, and the scenario-specific details above.

Apple doesn’t publish a fixed number of expedited requests you’re allowed per year. What its page does make clear is that this exists for extenuating circumstances, and developer reports consistently describe Apple tracking request history — asking routinely, for non-emergencies, makes a future request more likely to be declined. Treat it as a reserve for a genuine crash-on-launch or a hard-dated event, not a way to skip the queue on an ordinary release.

Does expedited review fix a bad keyword or metadata change faster?

Only indirectly, and only the review part. Expedited review shortens how long your version sits waiting for App Review — it does not change what happens after approval. If a bad keyword field or a broken subtitle shipped and you need the corrected version live immediately, an approved expedited review still has to clear whichever release option is set: automatic release goes live the moment it’s approved, but manual release sits in Pending Developer Release until someone clicks Release, and scheduled release waits for its date regardless of how fast approval came through.

So the real fix for a metadata emergency is two levers, not one: request expedited review to shrink the queue wait, and confirm the version’s release option is automatic (or manually trigger release yourself) so approval doesn’t stall a second time behind a setting nobody checked.

Before you submit an expedited review request

  1. Confirm your situation is actually one of Apple’s two documented scenarios — critical bug with reproduction steps, or a dated event with your app’s tie to it — not a self-imposed deadline.
  2. Submit through developer.apple.com’s Contact Us form, App Review topic, not through anything inside the version’s App Store Connect page.
  3. Check the version’s release option before you submit. An expedited approval on a manual-release version still needs someone to click Release; on scheduled release it still waits for its date.
  4. Save the request for when it’s real. Apple’s page frames this as extenuating-circumstances-only, and developers who ask routinely report their next request gets denied.