Apple says that on average 90% of App Store submissions are reviewed in less than 24 hours. Google Play reviews often finish within a few days, but Google warns that some take seven days or longer. New developer accounts, sensitive permissions, regulated categories, and incomplete review information cause most delays. Plan at least a week of buffer for launches, and use Apple's expedited review only for critical fixes.
What Apple and Google actually say
Apple's App Review page states that on average 90% of submissions are reviewed in less than 24 hours. In practice, simple updates are often approved within hours, while new apps, large feature changes, and apps in sensitive categories can take longer. Review times can also stretch around major holidays and right after big OS releases, when submission volume spikes.
Google does not publish a typical figure in the same way. Its help center says reviews may take up to seven days or longer in exceptional cases. Updates from established accounts with a clean history usually move faster than first submissions from new accounts. Both stores review updates as well as new apps, so a policy problem can delay a routine bug fix.
Why reviews take longer than expected
The biggest avoidable delay is missing information. If reviewers cannot log in, cannot find a feature, or need hardware they do not have, the submission is rejected or held while they ask questions. Each round trip adds a day or more. Detailed notes and a working demo account are the cheapest way to speed up review.
Other delays are structural. Apps requesting sensitive Android permissions, such as SMS, call log, background location, or accessibility services, go through additional checks. Financial, health, gambling, VPN, and kids apps attract closer scrutiny on both stores. New Google Play personal accounts must also complete a 14-day closed testing requirement before production access, which is a separate wait from review itself.
How to request an expedited App Store review
Apple lets developers request an expedited review for urgent situations, such as a critical bug fix that affects many users or a time-sensitive event tied to a release. You submit the request through the contact form with the app, the reason, and the impact. Apple reviews requests case by case and does not guarantee approval.
Use expedites sparingly. Requesting them for routine updates erodes their value, and they cannot fix a build that will be rejected anyway. For predictable events, such as a holiday campaign or an in-app event, submit early and use manual release to publish on the day.
Plan releases around review, not against it
The safest pattern is to decouple approval from launch. On iOS, submit early and choose manual or scheduled release so the approved build waits for your date. On Google Play, managed publishing lets you hold an approved release and publish it when you are ready. Both approaches turn review time into a predictable buffer instead of a launch risk.
Coordinate store assets with the build. Screenshots, subtitles, and keyword changes on iOS ship only with a new version, so a metadata test may wait for your release cycle. Promotional text can change anytime, and our guide to promotional text explains how to use it for time-sensitive messages without waiting for review.
Common mistakes that cost days
Teams often submit on a Friday afternoon before a Monday launch, discover a rejection over the weekend, and lose the launch date. Others change backend behavior after submission, so the reviewer sees a different app from the one described. Expired demo accounts and two-factor login prompts sent to an employee's phone are frequent blockers.
A pre-submission checklist prevents most of these. Confirm the demo account works from outside the office network, disable two-factor prompts for it, freeze backend changes during review, and check that metadata matches the build. Our explainer on the App Store Review Guidelines lists the rules behind the most common rejections.
A worked example: launch timeline for a seasonal campaign
Imagine a shopping app planning a holiday sale that starts on a Thursday. The team submits the iOS update and the Google Play release the Monday of the previous week, with clear notes and a demo account. Apple approves the build within a day and the team sets manual release. Google takes four days, and managed publishing holds the approved release.
On the Thursday, both releases go live together with refreshed screenshots and promotional text. Because the team planned a full week of buffer, a one-day rejection on Google Play for a missing Data safety detail did not threaten the date. Pairing this with a seasonal ASO calendar makes the process repeatable every year.
How to do it, step by step
- Freeze the build a week before launchTreat the submission date, not the launch date, as your deadline, and leave at least five business days for review and one rejection cycle.
- Prepare reviewer accessCreate a demo account without two-factor prompts, preload sample data, and test it from outside your corporate network.
- Write precise review notesExplain non-obvious features, hardware requirements, and where to find premium content. Link a short video if needed.
- Hold approval with manual releaseUse manual or scheduled release on iOS and managed publishing on Google Play so approval and launch are separate.
- Reserve expedites for emergenciesRequest an expedited App Store review only for critical fixes or genuine time-bound events, with a clear explanation of user impact.
Before and after examples
Illustrative examples written for a generic app in this category, not client results. Swap in your own product, audience, and data.
Submit Friday at 6pm for a Monday launch.
Submit Monday of the prior week, set manual release, and publish Monday morning.
Why it works: A full buffer absorbs one rejection without moving the launch.
Use your own email to sign in.
review@example.com / Review2026, two-factor disabled, premium unlocked, sample orders preloaded.
Why it works: Reviewers cannot receive your verification codes, and empty accounts hide features.
Please review faster, we have a launch.
Version 4.2.1 fixes a crash on launch affecting about 12% of iOS 26 users since yesterday's release. Crash logs attached.
Why it works: Specific user impact is what qualifies a request for expedited review.
Action plan
- Plan a five-business-day review buffer
- Decouple approval from launch with manual release
- Keep a permanent reviewer demo account
- Freeze backend behavior during review
- Track review times per platform in a release log
- Request expedites only for critical issues
Metrics to monitor
- Hours from submission to decision per platform
- Rejections per release
- Launch dates missed due to review
- Expedite requests made versus granted
Record the baseline, release date, audience, markets, and external changes before interpreting movement. Rankings and conversion are useful signals, but a decision is stronger when activation, retention, and business value confirm that the page attracted the right users.
Frequently asked questions
How long does App Store review take in 2026?
Apple states that on average 90% of submissions are reviewed in less than 24 hours. New apps and complex submissions can take longer, especially around holidays and major OS launches.
How long does Google Play review take?
Often a few days, though Google says some reviews take seven days or longer. First submissions from new accounts and apps with sensitive permissions usually take longest.
Why is my app stuck in review?
It may be waiting in a queue, under additional checks for sensitive features, or held because the reviewer needs information. Check for messages in App Store Connect or Play Console before contacting support.
Do app updates need review?
Yes. Both stores review updates. On iOS, only promotional text can change without a new version; on Google Play, store listing changes are also reviewed, usually quickly.
Keep reading
Go deeper on this topic
More in Platform Guides
Browse all 9 Platform Guides guides
Work with ASOWin
Primary sources
Platform capabilities and limits can change. Verify current requirements in these official resources:
