How long does app review actually take in 2026?
Apple says 90% within 24 hours; the live trackers mostly agree — until they don't. The real planning problem is variance, not averages, and it changes how you should think about shipping fixes.
Every mobile team plans around a number for "how long review takes," and almost every team needs a better kind of number. Public averages can be useful context, but they are not a promise. The day you desperately need a fast review is never an average day.
What the data says
Apple says that 90% of submissions are reviewed in less than 24 hours. Treat that as a directional service metric, not an incident plan: it does not tell you which submission will be in the remaining slice, nor when users will install an approved update. Google Play does not publish a comparable average; its publishing guidancesays certain accounts can face reviews of up to seven days or longer in exceptional cases.
What the averages hide
Three kinds of tail events to plan for:
- Queue variation. Review duration can vary by account, app, region, submission type, and operational conditions. It is not something a team can safely infer from a single public average.
- Extended reviews. Google explicitly notes that certain accounts may receive more thorough review; Apple does not offer an SLA for an individual submission. Build your launch plan with slack.
- Rejections and follow-ups. A rejection starts another fix-and-review cycle, and may require a conversation with App Review or Play. That is a planning risk even when a normal review is fast.
Put together: review time is a distribution, and you cannot schedule a production incident for its median. When a crash is burning your ratings right now, an approval target is not the same thing as a fix timeline.
What teams actually do about it
- Expedited review is available for extenuating circumstances on iOS, but it is not an SLA. We wrote up when and how to use it.
- Release trains stop treating each release as a bespoke event, which removes review latency from your feature planning. It's the single best process change for review anxiety — covered in the release-train playbook.
- An OTA channel can shorten the fix path for compatible JavaScript and asset changes. It does not remove the need to assess store policy or to send native changes through normal review. See the policy guardrails.
The reframe
The right goal isn't faster reviews — you don't control review speed. The goal is making review latency irrelevant to your emergencies. Reserve the store pipeline for what genuinely needs it (native changes, big feature launches) and keep a controlled fast path for compatible changes that remain within store policy. Teams that make that split stop watching the review-status page like a weather report, which — speaking from the other side of it — is a better way to live.