App Store review times: what to actually expect

Nobody outside Apple knows how long App Review takes. That is the honest starting point, and every number on this page is labelled with whose number it is.

Apple publishes one figure, on its App Review page: "On average, 90% of submissions are reviewed in less than 24 hours." That is Apple's claim about Apple's own process, it is not audited, and it is an average with a 10% tail that Apple does not describe.

Developer experience frequently does not match it. Reports of multi-day waits are constant and long-running, and in early 2026 there was a widely discussed run of unusually long reviews, with developers describing waits well past a week on submissions that would normally clear overnight. Those are reports, not measurements.

So: plan against Apple's figure being roughly right most of the time, and against it being useless to you on the day it is not.

Why there is no real number

Three structural reasons, and they are worth understanding because they explain why every "average review time" site you find is guesswork.

Apple publishes no per-submission data. There is no queue position, no estimated time, no historical distribution, and no API field that says how long anything took to review.

The crowd-sourced trackers are self-selected. Sites that collect developer-reported review times are built entirely from people who chose to report, and people report more readily when something is unusual. That skews in both directions at once and cannot be corrected for.

Apple's own figure is an average of a mix. A one-line bug fix to a five-year-old app and a brand new app with in-app purchases in a sensitive category are both "submissions". Averaging them tells you almost nothing about yours.

Anyone who quotes you a confident median is quoting a number nobody can verify.

What the statuses tell you, and what they do not

App Store Connect's own definitions, which are more precise than they look:

Waiting for Review. "You've submitted a new app or updated version. Apple received your submission, but hasn't started the review." This is the queue. Nothing is happening to your app. There is no position indicator and time spent here tells you nothing about time remaining.

In Review. "App Review is reviewing your app. You can remove the build from review." A human or an automated pass is now looking. In practice this status can last minutes or days, and it can also flip back and forth if the submission is passed between checks.

Metadata Rejected. "App Review didn't accept your metadata." Better news than a full rejection, because you can usually fix it without a new build.

Rejected. "Your app wasn't accepted." Apple notifies users with the Admin, App Manager or Developer role.

Developer Rejected. "You removed your app from review." Worth knowing this is what pulling a submission looks like, and that it puts you back at the end of the queue when you resubmit.

Pending Developer Release. Approved, waiting on you, because you chose manual release.

Processing for Distribution. "Your app is processing and will be ready for distribution within 24 hours." This is post-approval work, not review.

Ready for Distribution. Live.

The thing the statuses genuinely do tell you: In Review means the wait is over even if the review is not. Moving from Waiting for Review to In Review is the only real signal you get, and it usually means resolution within hours rather than days.

One more that surprises people: Waiting for Export Compliance, defined as "Your CCATS file is in Apple's export compliance review process." If your version sits there, it is not in App Review at all. It is in a different queue, and App Review cannot help.

What does not speed it up

This list is longer than the other one, and every item on it is something developers try.

Resubmitting. Removing a submission and resubmitting puts you back in the queue. It does not jump you forward. If your app has been in Waiting for Review for two days, resubmitting makes it three.

Contacting App Review to ask where it is. You will get a courteous reply that gives you no information, because the people answering do not control the queue.

Submitting at a particular time of day or day of week. There is a persistent belief that Sunday evenings or mid-week mornings are faster. No published data supports it, and Apple's review operation spans time zones. Treat this as folklore.

A bigger developer account, or more revenue. No published mechanism ties review speed to account size.

Filling review notes with pleading. Notes help a reviewer understand your app. They do not affect scheduling.

Paid services promising fast-track review. There is no such product. Nobody sells access to Apple's queue.

What plausibly does affect it

Not speed-ups exactly. More like avoiding self-inflicted delay.

Being reviewable at all. The single largest controllable factor is whether a reviewer can use your app. Working demo credentials, notes explaining anything non-obvious, and a build that launches. A rejection because a reviewer hit a login wall costs you a full round trip, which dwarfs any queue variation.

Not being a first submission. A brand new app is a bigger review than an update to an app Apple has already seen many times. This is widely reported and structurally sensible, though Apple does not state it as policy.

Not changing much. A submission that adds a new business model, a new permission, or a sensitive capability is a larger review than a bug fix. Again, reported rather than published.

Not being rejected. Every rejection restarts the clock. The fastest submission is the one you did not have to make twice, which is an obvious point that becomes non-obvious under launch pressure.

Expedited review

Apple does offer expedited review, and it is real. From Apple's App Review page, the circumstances are a critical bug fix in a released app, or a time-sensitive event.

For a critical bug, you submit the steps to reproduce the bug in the currently released version. For an event, you give the event name, the date, and an explanation of your app's association with it.

Requesting it means signing in and using Apple's contact form for App Review, under the expedite topic.

Four honest points about it:

It is a request, not a switch. Apple grants or declines. There is no appeal and no stated criteria beyond the two circumstances.

"Critical" means users are broken now. A crash on launch in the live version qualifies. A feature you promised a customer does not.

Spending it costs you. Developers widely report that frequent expedite requests get less sympathy over time. Treat it as something you use once or twice a year.

It does not help a rejected app. Expediting speeds up the queue, not the disagreement. A rejection you dispute goes to the resolution centre, or to the App Review Board, which is one appeal per rejected submission.

How to plan a release around this

The practical answer is not a number, it is buffer and sequencing.

Submit earlier than you need to, and use manual release. Choose "Manually release this version" and let the app sit at Pending Developer Release until you are ready. This decouples review time from launch date entirely, and it is the single most useful habit on this page. Note that Apple emails a reminder if a version sits there for more than 30 days.

For a dated launch, submit at least a week ahead. Not because review takes a week, but because one rejection plus one resubmission comfortably does.

For a critical fix, submit immediately and then request expedited review. In that order. The request references a submission.

Do not announce a date you cannot control. If a press embargo or a partner launch depends on the exact hour, the version needs to be approved and held before the announcement goes out.

Check the status, not your email. The version page in App Store Connect is authoritative, and email notification is not instant.

The summary, with attributions attached

Apple says 90% of submissions are reviewed in less than 24 hours. Developers report frequent exceptions, and reported a sustained slow period in early 2026. No one outside Apple has authoritative numbers, and this page is not going to invent one.

What you can control: being reviewable, submitting early, holding the release yourself, and not needing a second attempt.

AppSubmit polls submission status and tells you when it changes, which removes the reflex to refresh App Store Connect, but it cannot see the queue either. Nobody can.