Apple clears 90% of submissions in under a day. Expedited review is not what fixes the other 10%.

The email always arrives in the same shape. It has been six days, the app is still sitting in Waiting for Review, the launch was supposed to be tomorrow, and can I please call someone at Apple.

I cannot. Nobody can. What I can usually do is work out what the six days mean, and after eighteen years of submitting apps I can tell you it is rarely queue depth.

There is a button for this. Apple lets you ask for an expedited review, it costs nothing, and when it is granted it works within hours. Most of the people who press it are in a situation it cannot help with.

The number Apple publishes, and the one underneath it

Apple states it plainly on its App Review page: "On average, 90% of submissions are reviewed in less than 24 hours."

The figure is true. The remainder is where you probably are. In 2025 the App Review team evaluated more than 9.1 million submissions, about 25,000 a day, so the slow tenth works out at roughly 900,000 submissions a year that took longer than a day. Plenty of company, in other words, and what matters is knowing what put you there.

It also helps to know how little time a review takes. Apple's own description of the operation a year earlier was nearly 500 dedicated experts reviewing over 130,000 apps a week. Jeff Johnson of Lap Cat Software did that division in May: about 260 submissions per reviewer per week, under ten minutes each. In a deposition in the Epic case, a former head of App Review put a new app at about thirteen minutes.

So nobody is spending six days examining your app. A review is minutes of attention. The six days are the time before somebody picks it up, or the time the submission spent routed somewhere slower than the main queue, and both leave traces in your own dashboard.

Why a submission sits there

In rough order of how often I run into them, and the first one covers most of it.

• The first submission from a young account is the slowest thing you will ever send Apple. In 2025 Apple rejected more than 138,000 developer enrolments and terminated 193,000 accounts over fraud concerns, so an account with no history carries a different risk profile from one with forty shipped versions behind it. Updates to an established app go through in hours. First submissions do not.
• Some categories pull extra checks: finance, health, kids, dating, VPNs, crypto, gambling, anything with a medical claim attached. Apple's review page lists the paperwork it may ask for, including clearance for medical hardware, trademark authorisation and licensing. A submission waiting on a document Apple does not have is parked rather than queued.
• App Review may have already written to you. Apple says over 40% of unresolved issues relate to guideline 2.1, App Completeness, which covers crashes, placeholder content and incomplete information. The everyday version is a demo account that stopped working, or a backend you switched off after testing. That kind of wait ends the moment you answer it.
• The calendar does a lot of work here. Apple posts a notice every December telling developers to submit time-sensitive work early because reviews take longer from December 20 to 26. September brings the new OS and everybody shipping compatibility updates in the same fortnight. And 2026 is a heavy year for volume anyway: iOS releases were up 80% year over year in the first quarter, with nearly 560,000 new apps arriving in the first half.
• Some of it is not App Review at all. Agreements, tax and banking sit outside the review process and block distribution on their own. A paid app whose Paid Apps Agreement is unsigned cannot go on sale whatever a reviewer decides, and the dashboard makes that look like a review delay.
• Some of it is self-inflicted. Removing a version from review sets it to Developer Rejected and the review starts again from the beginning, and editing anything outside the small set of fields that stay open during review means removing it first. People do that on day four, then count the wait from day one.

What an expedited review actually is

Apple names two situations on its App Review page. One is a critical bug fix, where Apple asks you to "include the steps to reproduce the bug on the current version of your app". The other is an app tied to an event, where the request should carry "the event, date of the event, and your app's association with it". You make the request through a form on the developer site, signed in, once the submission is already in the queue.

It moves your submission forward in the queue. The review itself is the same review, held to the same standard, only earlier. An expedited app gets rejected on Tuesday morning for exactly what would have got it rejected on Friday afternoon.

When it is granted, it is fast. The answer to the request usually arrives the same day or the next one, and the review lands within hours of that answer. That speed is the whole appeal, and it is the reason to be careful about what you spend it on.

Read Apple's wording on the event case, because it gives the game away. Apple recommends you plan and schedule the release in App Store Connect, and only then adds that if the app is still in review and the event is approaching, you can ask for the review to be expedited. Apple's first answer to a deadline is the release scheduler. The expedite form comes second.

How to write a request that gets granted

One paragraph, specific, checkable by somebody who has never seen your product. For a bug: what breaks, since which version, for which users, the steps to reproduce it, what the fix changes, and a number that shows scale. A crash rate, a count of support tickets, the one-star reviews that landed in the last 48 hours. For an event: the date, your app's connection to it, and why the date cannot move.

The requests that fail are the ones that are urgent for you and invisible to Apple. The campaign starts Monday. The client was promised Friday. The investor demo is Thursday. We are already late. Every one of those is a real problem and none of them is a bug or an event.

Ask once, through one channel. A form submission plus a support case plus a forum thread about the same build does not multiply your odds, and the person reading the request can see all three.

The limits, which Apple does not put in writing

• There is no published quota. Apple's language is extenuating circumstances, and each request is judged on its own. Plan on roughly one a year and you will be about right.
• Requests are remembered. Ask often and they quietly stop being granted, with no warning and no notice, and you find out on the day something is genuinely broken that you spent it on a marketing date.
• It cannot turn a rejection into an approval. If the expedited review finds a guideline problem, the request is spent and you fix and resubmit like everybody else. Appeals run on a separate track through the App Review Board, one appeal per submission that did not pass, and Apple asks you to answer any outstanding request for information before you file one.
• It cannot reach anything outside App Review. An unanswered 2.1 message, unsigned agreements, incomplete tax or banking details, a pending enrolment, a build that crashes on the reviewer's device. A granted request moves none of them.
• Google Play has nothing like it. Play says a review can take up to seven days or longer in exceptional cases, and a personal developer account created after 13 November 2023 also has to run a closed test with at least 12 testers opted in continuously for 14 days before it can apply for production access. No form shortens that, so the only way to make it cheap is to start it early.

Four things that work better

Submit early and hold the release. Apple lets you approve a version and then release it by hand or on a date you pick. Play has managed publishing, which keeps approved changes back until you say so. Once approval and launch are two separate events, review time comes off the critical path. Most of the expedite requests I have watched go out were the bill for skipping that one step.

Build the fix so it does not need a submission. Feature flags and remote configuration put the switch inside a binary Apple has already reviewed and leave your server to decide which way it is flipped. That is ordinary practice, and it is a different thing from what guideline 2.5.2 forbids, which is downloading code that introduces or changes features. The catch is that a kill switch has to ship in version 1, not in the release you are currently waiting on.

Fill in App Review Information as though a stranger has to use it, because one does, in under ten minutes, on a device that is not yours. A demo account that works today, the backend left running, notes for anything a reviewer would not guess, a short video for a flow that needs hardware. Guideline 2.1 is more than 40% of unresolved issues and it is the cheapest delay on this list to remove. If you have already been rejected, I wrote separately about what Apple rejects under 4.2 and 4.3, and there is a page here on getting a rejected app through.

Ship often enough that no single release is load-bearing. When your releases are a fortnight apart, a two-day review is noise. When you ship twice a year, every submission carries a quarter of the roadmap and every review is an emergency. It is the same cadence argument I made about releasing early, and it applies to review timing as directly as it applies to ranking.

There is a fifth that does not shorten a review at all and still solves the problem more often than people expect. Up to 100 people on your own team can install a TestFlight build within minutes of upload, with no review. External testers need Beta App Review for the first build of a version, which is a shorter and separate queue. If what you need this afternoon is real people running the fix, that road avoids the store.

The one case where I would not hesitate

Data loss. A crash on launch. A security hole. Payments taking money and delivering nothing. Anything where every hour costs users something they cannot get back. That is what the mechanism was built for, the request writes itself, and I would send it within the hour.

I would also assume it might be declined and do everything else in parallel: a server-side mitigation if the app has the plumbing for one, a note wherever your users are already complaining, and the fix sitting in the normal queue so it is moving either way.

The wait is a planning problem

Expedited review is a favour with a memory. It is worth about one good emergency a year, and it changes when your app is reviewed rather than how.

The teams who never seem to be waiting on Apple are not the ones with a contact inside the company. They are the ones who submitted a fortnight before the date they cared about, and who can switch a broken feature off from their own server while the fix goes through the ordinary queue like everybody else's.