How long does App Review actually take?

Apple publishes exactly one number about App Review: on average, 90% of submissions are reviewed in less than 24 hours. It's true — and it's also not the number that matters. Nobody plans a launch around the average; you plan around the tail, and most of the tail is self-inflicted. Here's what actually decides whether you wait a day or a week.

The official numbers

Apple's claim, straight from its App Review page: on average, 90% of submissions are reviewed in less than 24 hours. In practice, a routine update from an established account with a clean history often clears in a few hours. Apple has spent a decade grinding review times down from the week-long waits of the early App Store, and for the common case it shows.

Google doesn't commit to anything that tight. The official guidance is that review can take up to seven days, and longer in exceptional cases. The reality is two-tier: updates from established developer accounts usually clear in hours to a couple of days, while a first app from a brand-new account routinely sits at the long end — a week or two is normal there, not a malfunction. Google applies extra scrutiny to new accounts by design, and no amount of resubmitting hurries it along.

One mental-model correction before anything else: review is not a queue you can jockey. There's no position to buy and no trick to move up. The only lever you actually hold is whether your app can be reviewed in one pass — and that lever is worth more than every other tactic combined.

What puts you in the tail

The submissions that blow past 24 hours mostly share a few traits, and almost all of them are avoidable:

It's your first submission. A new app gets walked end to end; an update gets compared against a known history. Budget real calendar time for v1.0 — this is the one review you can't make fast.

There's a login wall and no demo account. If a reviewer can't get past your first screen, the review is over and the clock resets. Put working demo credentials in the App Review Information section, make sure they bypass SMS codes and 2FA, and — the classic self-inflicted wound — sign in with them yourself the day you submit. Expired demo credentials have delayed more launches than any policy ever has.

First-time in-app purchases. New IAP products are reviewed alongside the binary that introduces them, which adds surface area. Submit them with the build, fully configured with screenshots and localized copy, rather than as an afterthought.

Sensitive territory. Background modes, health data, anything aimed at kids, anything touching money — all of it correctly attracts extra checks. Nothing to fix here, just buffer to add.

The reviewer can't find what your listing promises. If your screenshots or description claim a feature the reviewer can't reach, expect questions or a metadata rejection. And use the reviewer notes field like it matters, because it does: explain the non-obvious flow, say where the paid features live, justify the scary permission. A confused reviewer does not guess in your favor.

The real delay is the rejection loop

A rejection doesn't add a day — it adds a round trip: their review, your response time, their re-review. Take a weekend to reply and a 24-hour review becomes a week. This is where launch timelines actually die, and it's why the single best habit is boring: answer the Resolution Center the same day. A fix-and-resubmit on an open rejection generally turns around faster than a cold submission, because the context is already loaded.

If you think the rejection is wrong, disagree like a colleague, not a defendant. Reply in the thread, cite the specific guideline, explain calmly why your implementation complies — reviewers reverse defensible calls more often than people expect. If that stalls, a formal appeal to the App Review Board exists. What never works is shipping an argument in your release notes.

Expedited review is a fire alarm, not a fast lane

Apple does have an expedite request form, and it names exactly two qualifying circumstances: a critical bug in your live app, or a launch tied to an event you're directly associated with. For a bug, include reproduction steps against the current version; for an event, name the event, the date, and your association with it. Requests are judged case by case with no guarantee.

Treat it as goodwill you can burn. Ask never, so that the day a crash-on-launch build escapes to production, your request is credible and granted. Devs who expedite every minor release are spending exactly the credibility they'll one day need.

Plan the release, not the submission

The cleanest trick in the whole topic: decouple approval from release. On iOS, choose manual release or a scheduled release date, submit a week early, and let the approval sit ready while you line up the announcement. On Google Play, managed publishing does the same job — approved changes go live when you push the button, not when review happens to finish. Once you work this way, review time stops dictating launch time entirely, and the 90th-percentile horror story becomes someone else's problem.

For updates, both stores also let you soften the landing: Apple's phased release ramps an update to automatic-update users over seven days (1% → 2% → 5% → 10% → 20% → 50% → 100%, pausable at any point), and Play's staged rollouts let you pick a percentage and halt if crash rates move. The thing to fear was never shipping — it was shipping everywhere at once.

The one delay that's entirely optional

Of everything above, the metadata rejection is the purest waste — a binary that passed, held up because the listing overpromised or a screenshot showed something the app doesn't do. We wrote about exactly how screenshots get apps rejected, and it's the reason ShotCanvas templates keep your frames inside the rules by construction: real UI, honest framing, exact per-store dimensions, exported or published straight to both consoles.