Apple reviews 90% of submissions in under 24 hours. Google says a few hours to seven days. What the statuses mean, when to expedite, and four things people believe about review times that neither store documents.

Apple publishes one number: 90% of submissions are reviewed in less than 24 hours.

Google publishes a range: a few hours or up to seven days, or longer in exceptional cases, and recommends you plan a buffer of at least a week between submitting and going live.

That gap explains most release planning mistakes. People schedule around Apple's number and get caught by Google's.

What the statuses actually mean

Apple's own definitions, which are more precise than how anyone uses them:

Status What it means
Prepare for Submission You have an app record and are still filling it in
Ready for Review You entered the metadata and said you intend to submit. You have not submitted.
Waiting for Review Apple has your submission but has not started
In Review Someone is looking at it. You can still pull the build
Metadata Rejected The build is fine. Something in the listing is not
Rejected The submission did not pass
Accepted This item passed, but something else in the same submission did not. Nothing publishes until everything passes
Pending Developer Release Approved. Waiting for you to press the button
Processing for Distribution Approved and released. Live within 24 hours
Pending Apple Release Held until the matching OS version ships publicly
Ready for Distribution Live

Two of these cause most of the confusion. Ready for Review is not submitted. And Accepted does not mean published: if you submitted an app version alongside other items and one of them failed, the accepted parts sit and wait.

When it takes longer

Apple documents exactly one cause: incomplete submissions. In its own words, if your submission is incomplete, review times may be delayed or your submission may not pass. Over 40% of unresolved issues come from Guideline 2.1, App Completeness.

Beyond that, Apple names categories that get more scrutiny rather than more time. Medical apps that could provide inaccurate data or be used for diagnosis are reviewed with greater scrutiny. Health research apps need ethics board approval. Apps in banking, healthcare, gambling, cannabis, air travel and crypto exchanges are expected to be submitted by the legal entity providing the service, not by an individual developer.

One structural limit worth planning around: you can have one app version under review per platform at a time, and a maximum of two submissions under review at once. Since October 2025 you can send other items independently, so a critical bug fix no longer has to wait behind a custom product page that is still in review.

Expedited review

Apple has it. Google does not publish any equivalent.

Apple grants expedited review for extenuating circumstances, and names two: fixing a critical bug, or releasing to coincide with an event you are directly associated with.

What to include, per Apple:

  • Bug fix: steps to reproduce the bug on the current live version. Not a description of the fix. The reproduction.
  • Event: the event, its date, and your app's association with it.

Apple also says the better answer for an event is to schedule the release in App Store Connect rather than racing review. That is worth taking seriously, because scheduling costs nothing and expediting spends goodwill.

If you are rejected and you believe the reviewer misread your app, there is a separate route: an appeal to the App Review Board. One appeal per failed submission, and answer any outstanding requests for information first.

Four things people believe that neither store documents

All four get repeated as fact, including by people who should know better.

"Resubmitting puts you at the back of the queue." True on Google, and Google says so plainly: the turnaround time is counted from the last submitted change, and your app may be pushed to the back of the review queue. Apple documents nothing of the kind. The closest Apple statement is that submissions may not be reviewed in the order you submit them.

"Metadata-only updates are faster." Apple publishes no such claim, and there is barely such a thing to be faster at. Most listing changes need a new version, which needs a build. The documented exceptions are promotional text, which you can change at any time, plus support URL, marketing URL, review information and release notes. Everything else waits for a version.

"New accounts and first submissions are slower." Not documented by Apple anywhere. It may be true. Apple has never said it.

"TestFlight review is quicker." External TestFlight builds do go through a separate Beta App Review, with its own statuses and its own queue. Apple publishes no timing for it and no comparison to App Store review.

If you are planning a launch, plan on what is documented and treat the rest as folklore.

The holiday question

Apple used to close. The last actual shutdown was December 2020.

Since then it has stayed open and posted an early-December warning instead. The most recent was 2 December 2024: submissions accepted throughout, submit time-sensitive work early, reviews may take longer from 20 to 26 December. Apple posted no such notice in 2025.

So the honest advice is that there is no shutdown to plan around any more, but December remains the worst month to leave a release until the last week.

Google's separate gate

Play has a delay Apple does not, and it hits exactly the people who least expect it.

Personal Play Console accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for 14 days before applying for production access. That application is reviewed on its own, usually within seven days.

For a first-time solo developer that is two weeks of testing plus a week of review before the normal review clock even starts. Google's own pre-review checks help catch problems in advance and usually finish within fifteen minutes, which is the one part of the Play flow that is fast.

Planning numbers to actually use

  • Apple, routine update: assume one day, plan for three.
  • Apple, first submission: same review time, but budget days for the things that fail 2.1 before you get there.
  • Google, established account: plan a week.
  • Google, new personal account, first app: plan a month before anything can go live.
  • Anything tied to a date: schedule the release rather than expediting, and submit at least two weeks out.

What Uprate does with it

The submission agent catches the blockers and gives you the exact field and the fix before you submit. The fastest review is the one you do not have to do twice.

Nothing goes live until you approve it.

Was this article helpful?