Why App Review Feels Slower Than Apple Says It Is

Apple states that "On average, 90% of submissions are reviewed in less than 24 hours." Developers regularly report waits measured in days. Both of those things can be true at once, nobody has to be lying, and the reason is almost entirely in the definitions.

Here is the discipline for the rest of this piece. Apple's claim is labelled as Apple's claim. Developer experience is labelled as developer experience. The gap between them is labelled as unmeasured, because it is.

What Apple actually claims

On Apple's App Review page, under the heading "Review status", the text reads:

On average, 90% of submissions are reviewed in less than 24 hours.

That is the whole claim. It is one sentence, it is an average, and it is about "submissions" being "reviewed".

The same page makes two more claims worth having in front of you, because they are the ones that predict your own wait:

On average, over 40% of unresolved issues are related to guideline 2.1: App Completeness, which covers crashes, placeholder content, incomplete information, and more.

If your submission is incomplete, review times may be delayed or your submission may not pass.

And on what to put in App Store Connect before you submit:

If your app requires specific settings, user account information, or special instructions, include these details in the App Review Information section of App Store Connect. If you don't include this information, the app review process may be delayed and your app may not pass review.

Those are Apple's words, on Apple's page, and they are the only authoritative numbers in this article.

Nobody outside Apple has the real numbers

Apple publishes an average. It does not publish a distribution, a median, a 95th percentile, a per-storefront breakdown, a per-category breakdown, or a definition of when its clock starts and stops.

That last omission matters more than it sounds. If the clock starts when a submission enters the review queue rather than when you press Submit, then every hour your build spends processing beforehand is outside the measurement and inside your week.

Third-party review-time trackers exist. They work by collecting reports from developers who chose to submit a report, which is not a random sample of App Store submissions. People are more motivated to log a four-day wait than a two-hour one, so those datasets measure their own respondents rather than the App Store.

That is not a reason to sneer at them. It is a reason not to quote a figure from one as if it were a rate, so this article does not quote any.

Where the gap hides

Seven mechanisms, most common first. Any one of them is enough to produce a slow week alongside a fast average.

1. "Submissions" is a wider unit than "app versions." Apple's submission model lets you "Include multiple items in one submission", and those items can include in-app purchases, in-app events, custom product pages and product page optimization tests. A submission carrying one small in-app event is a submission. So is your annual rewrite. They count the same in an average, and they do not take the same time.

2. "Reviewed" is not "approved", and neither is "on sale." A rejection at hour six is a review completed inside 24 hours. It is also, from your side of the desk, the start of the problem rather than the end of the wait. Apple's sentence is about review completing, not about your app shipping.

3. Your wall-clock wait spans states that are not review. Between pressing Submit and having customers download the thing, you pass through build processing before the build is even selectable, then Waiting for Review, then In Review, then possibly Pending Developer Release, then possibly a phased release you chose yourself. Only two of those are review. All of them are your wait, and the phased rollout is not Apple's fault at all.

4. An average tells you nothing about which tail you are in. Ninety per cent inside 24 hours leaves a remainder, and the remainder is not randomly distributed. In practice the slow cases cluster: first submissions from a brand new account, regulated categories such as gambling, health, finance and anything aimed at kids, apps that need supporting documentation or a demo account, and anything that trips a manual escalation. If you are in one of those groups, the population average is not describing you.

5. A rejection resets your position. Two rejections plus two replies is three separate reviews. Each one can individually land inside 24 hours while your calendar quietly loses a week, and each reply of yours adds your own response time on top. The average is per review. Your deadline is per release.

6. Apple has a calendar too. Submissions around the annual OS release window behave differently from a random Tuesday in March, and so do submissions in the last fortnight of December. Reviewers are in specific time zones, so "24 hours" from a Friday evening submission is not the same 24 hours as from a Tuesday morning one.

7. What you control genuinely moves the number. Apple's own figure says over 40% of unresolved issues sit under guideline 2.1: crashes, placeholder content, incomplete information. That is the single best-evidenced statement anyone has about why submissions go slowly, and it is about the submission, not the queue. A working demo account, complete App Review Information, no placeholder copy, and a build that does not crash on the current OS are the levers you actually hold.

Your own sample size is one

You have a handful of submissions a year and a memory that over-weights the bad wait. That is not a criticism, it is arithmetic. Four days in Waiting for Review is memorable in a way that six approvals in an afternoon is not.

So keep timestamps. Log the moment you upload, the moment the build finishes processing, the moment the state changes to Waiting for Review, to In Review, and to whatever it lands on.

Do that for a year and you have something better than an argument: you have your own distribution, for your own app, in your own category. That is the only dataset on this subject you can honestly claim to own.

It also changes the conversation with your team from "review is slow at the moment" to "our last five updates cleared in a median of nine hours and one took three days after a 2.1 rejection." One of those sentences is useful for planning a launch date.

What would actually settle it

A distribution, not an average.

Publish the spread rather than the mean: median, 90th percentile, 99th percentile. Break it down by storefront and by app category, because a finance app in one region and a to-do list in another are plainly not the same queue. Define the state transitions, so everyone knows whether the clock starts at Submit or at the front of the queue. Separate first submissions from updates, because they behave differently and everyone knows it.

Apple could publish that. It has the data by definition, it already publishes an average from the same source, and nothing about a percentile distribution reveals anything competitively sensitive.

Developers cannot produce it, no matter how many spreadsheets we compare, because each of us sees only our own apps and the sample self-selects towards the annoyed.

Until then, the honest position is the uncomfortable one. Apple's average is Apple's average and there is no reason to think it is false. Your four-day wait is your four-day wait and there is no reason to think you imagined it. The relationship between the two is not something anybody outside Apple can currently measure, and anyone who quotes you a confident number for "current review times" is quoting a sample, not a rate.

AppSubmit records the timestamp of every state change on a submission and keeps them, which is how you end up with your own distribution rather than a feeling. You can do exactly the same thing with a spreadsheet and the dates in App Store Connect.

How long does Waiting for Review take (waiting-for-review-how-long)
What In Review actually means (in-review-status-meaning)
Every App Store Connect status explained (app-store-connect-statuses-explained)
Metadata Rejected versus Rejected (metadata-rejected-vs-rejected)
Pending Developer Release (pending-developer-release)

Source

Apple, App Review: https://developer.apple.com/distribute/app-review/ (all quoted claims checked 17 August 2026; developer.apple.com/app-store/review/ forwards here)