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 heavy change: two to five days is a better prior than 'tomorrow'. Kids apps, new entitlements, payments, Health, and anything that looks like a new product inside an old listing drift toward the long end. Apple said in June 2026 that 90% of submissions cleared within 48 hours, with a 1.5-day average across a very large weekly volume. That average still includes metadata nits and binary updates. It is not your launch date.
- 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 on a new personal account: the review of the binary is not the thing that dominates. You need a 14-day closed test with at least 12 testers, then a production-access review (Google says usually seven days or less), then the release review. End to end, a new personal account is weeks, not a weekend.
Apple's App Review page still says 90% of submissions are reviewed in less than 24 hours. That sentence has been on the page for years. Use it as a population statistic, not as the date you tell a journalist.
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 want the same two-week delivery sprint used to get these four onto devices — including the store packaging, not just the screens — that is the work. The construction is the short part. The queue is on Apple and Google's clock, and it always was.