Founders ask this as if it were a number. It isn't. Apple and Google both review apps; neither promises a deadline; both publish a typical window that people then treat as a contract. I ship four consumer apps on both stores — Luna, Smart Clip, Routina and Callendar — so what follows is the calendar I actually plan against in 2026, not a scraped 'average review time' graphic.
The honest ranges, not a promise
These are planning numbers. A given binary can be faster or slower. Treat them as buffers, not SLAs.
- Apple, routine update to a live app: often 24–48 hours. Plenty still clear in under a day. That is the case I plan for when the change is a bug fix or a small feature on an account Apple already knows.
- Apple, first submission or a substantial change: I allow two to five days as a planning buffer, with more room for sensitive features. Apple’s review-status help gives review goals of 50% within 24 hours and 90% within 48 hours. These are aggregate goals, not a deadline for your app.
- Google Play, established app, production update: often hours to a couple of days. Google's own wording is still 'a few hours up to seven days, longer in exceptional cases'. I submit important Play releases days early, not hours early.
- Google Play, first production for personal accounts created after 13 November 2023: the official testing requirements include at least 12 opted-in testers for 14 consecutive days, followed by an application for production access. Google says that access review usually takes seven days or less, sometimes longer. It is separate from review of the release.
Checked 8 October 2026: Apple’s general App Review page gives a different aggregate statistic: 90% in under 24 hours. The two official pages describe different targets. Neither is an individual launch guarantee; use the status in App Store Connect and leave a buffer.
A dual-store release is as slow as the slower store
If the product has to appear on both stores on the same morning, you do not get the Apple median or the Play median. You get whichever finishes last, plus the rejection you should have budgeted for.
The practical calendar I use:
- Cut the binary when the product is actually done. Not when the landing page is done. Store review does not test your website.
- Submit Apple first if the change is guideline-sensitive. Kids, keyboards, background modes, 'it rings like a phone call'. Apple is the one that will argue with the product, not just the listing.
- Submit Play with a buffer, not a hope. A routine update is often fast. The update that touches policy declarations, target audience, or a new permission is the one that sits.
- Assume one rejection on a first version. A rejection is another full review cycle, not a same-day rubber stamp. If the launch has an external date, that is two cycles of buffer, not one.
What actually stretches the queue
Not 'the reviewer had a bad day'. The same four things, every year:
- The app is for children. Luna is a bedtime-story app for roughly ages two to nine. Kids category, COPPA-shaped privacy, generated text. Apple reads that as a content and safety review, not a binary checksum. Plan longer than a weather-app update.
- The app can see what you type. Smart Clip is an AI keyboard and a share-sheet writing tool. 'Full Access' on iOS is a trust conversation. Privacy copy, data-not-sold claims, and a boring demo video matter more here than a new icon.
- The app claims to help with anxiety or attention. Routina is a leave-home checklist for ADHD brains — lock, gas, keys, logged. It is not a medical device. The listing has to stay in that lane. Health-adjacent wording is how a 24-hour update becomes a week.
- The app does something the OS already does, louder. Callendar fires a meeting alarm that behaves like a phone call, through Silent and Focus. Anything that looks like it is fighting Do Not Disturb gets a human look.
Framework choice is almost never why review is slow. Native vs Flutter vs React Native changes the binary, not the reviewer.
What this looked like on the four apps
I will not invent per-build hour counts. Review times are not a leaderboard, and a single lucky binary teaches you the wrong lesson. The pattern from shipping these four:
- Luna — lunastorytelling.kids. First kids listing was the slow one. Subsequent story-engine and localisation updates have behaved like ordinary updates, as long as the age rating, privacy nutrition label and generated-content story stay consistent with what Apple already approved.
- Smart Clip — smart-clip-app.com. Keyboard + 30-language writing. The permission and privacy story is the review. The code change is usually not.
- Routina — routina-app.com. Checklist, haptics, on-device photos. Updates that only change copy and taps go through like a utility. Anything that sounds like treatment does not.
- Callendar — callendarmeetings.com. Calendar alarms that ring. The first version had to show the alarm on a device in the review notes. After that, small calendar-sync fixes have been uneventful.
Play, on the same four, has been faster on routine production updates and slower the one time a listing or questionnaire was out of date. The binary was fine. The form was not.
How to plan a date you can actually keep
- Do not announce a store day until the first binary is in review. Landing pages can go live. Press should not.
- Keep a second, smaller binary ready. If Apple rejects a wording, you want a resubmit the same afternoon, not a new sprint.
- Write the review notes like a demo script. 'Tap this, then this, you will see X.' Reviewers are not your users.
- Match the privacy labels to the build. A keyboard update with last year's nutrition label is how you buy a week.
- If the account is new on Play, start the 12-tester closed test the day you have a crash-free build. That 14-day clock does not care that your website is ready.
The question to ask a supplier
Not 'do you know how long review takes?' Everyone will say 24 hours.
Ask: 'when do you submit relative to the date we told the board, and what happens if Apple says no once?' The answer tells you whether they have shipped a store app in 2026 or are quoting a blog post from 2022.
If you need a scoped delivery sprint for your app, we agree the scope, timeline, and price before work starts. The agreed scope can include store preparation. Store review sits outside that timeline; Apple and Google control how long it takes.