Apple publishes a review speed goal, not a promise, and the slow tenth has no ceiling.
The number everyone repeats is real, and it is a goal. Apple's words, on two App Review Help pages and nowhere else, are that App Review works around the clock with the goal of reviewing at least 50 percent of submissions in less than 24 hours and 90 percent in less than 48 hours. Read 17 October 2026. That is a target about Apple's whole queue. It says nothing about your submission, it is not a service level agreement, and Apple publishes no figure at all for the one submission in ten that misses it. Nothing in the App Store Review Guidelines mentions a review duration. The number lives only in a help article, which is the first clue about how firm it is. If you are trying to work out your odds rather than your wait, start with why apps get rejected.
Google publishes the opposite shape. No target, no percentages, no average, and a ceiling instead: a few hours or up to seven days, or longer in exceptional cases. Read the same day. Two stores, two numbers, and almost everyone quotes Apple's target as if it were a guarantee and Google's ceiling as if it were a typical wait. Both readings are wrong, in opposite directions.
Start hereThe short version
Plan for two days on iOS and a week on Android, and hold neither store to it.
In practice an ordinary iOS update clears in hours and an ordinary Android update clears in hours too. Neither store will say so. What they will say is the outer edge of what they are willing to put in writing, and those two statements are built differently on purpose. Apple names a fast target and refuses a ceiling. Google names a ceiling and refuses a target.
So the honest answer to how long review takes is a planning answer, not a figure. Apple's own slower case, a submission needing paperwork checked or a capability nobody has shipped before, has no published bound. Google's planning advice is a buffer of at least a week. Build the later of those two into the date you tell people, then be pleasantly surprised. The one thing you fully control is when an approved build reaches customers, not when it gets looked at.
What does Apple actually promise about review speed?
Nothing. Read the sentence slowly and every load-bearing word is a hedge. Goal, not commitment. At least 50 percent, which is a floor on a proportion and not on your wait. Of submissions, meaning everyone's, not yours. Less than 24 hours, with no stated window over which the proportion is measured. The sentence is a description of throughput. It cannot be breached, because nothing in it was offered to you.
Two further details make this concrete. The first is where the sentence lives. It appears on exactly two pages of Apple's App Review Help, the one about tracking a submission's status and the one about requesting an expedited review. It does not appear in the App Store Review Guidelines, which were last updated on 16 October 2026 and which do not contain the strings 24 hours, 48 hours, 50 percent or 90 percent anywhere. The Guidelines' own paragraph on timing says only that App Review will examine your app as soon as we can. Apple keeps the number out of the document it holds you to.
The second is that Apple contradicts its own figure further down the same page. The article opens with the goal of 90 percent in less than 48 hours. Under the heading explaining why some reviews take longer, the same article says most submissions are reviewed within 48 hours. Most is not 90 percent. One of those is a target Apple set and the other is a description of what happens, and the weaker version is the one Apple reaches for when it is about to explain a delay. Treat that as the real planning number.
There is also no ceiling, and that absence is specific rather than vague. Across every page of Apple's App Review Help, the words service level agreement and SLA do not occur, and no maximum review time is stated. The word guarantee appears twice, and both times it is Apple withholding one: a complete appeal does not guarantee the App Review Board overturns the decision, and a 30 minute Meet with Apple appointment does not replace, expedite, or guarantee the outcome of your review. The only durations Apple does commit to in that help section are about other things entirely, such as calls typically completed within three to five business days, or a 90 day window to update an app flagged under App Store Improvements.
Apple, App Review Help, track a submission's review status, read 17 October 2026
Who does Apple document as waiting longer?
This is the part of the documentation worth reading, and almost nobody quotes it. Apple names two reasons a submission needs additional time for verification. Documentation review, which is when App Review has to request and verify supporting materials such as authorisations, licences or partnership agreements before approving. And complex or novel issues, which covers regulated content, new platform capabilities, enabled entitlements and other sensitive features that need greater scrutiny. If either describes your app, the goal was never about you, and the fix is in your hands: attach every required document in the App Review Information section before you submit rather than after a reviewer asks.
The Review Guidelines add a third category, and it is a penalty rather than a workload. If your app is repeatedly rejected for the same guideline violation, or you have attempted to manipulate the review process, review of your app will take longer to complete. That is Apple's own wording. Nothing says how much longer, or how many repeats trigger it, or whether it ever decays. The Guidelines also tell anyone shipping gambling, lotteries or real money gaming to be prepared for extra time during the review process. So slow review is partly a function of your history, which is a strong argument for fixing every issue a reviewer raises before you resubmit.
Apple is blunt about the most common self-inflicted delay. Resubmitting with unresolved issues delays review and results in the same outcome. Resubmitting also starts a new review, after which App Review can no longer reply to your earlier message, and it closes an appeal if one is open. When a reviewer only needs information, reply in App Store Connect instead of uploading again. Most of the timeline advice people swap is really about this: the queue is fast, and the round trips are slow. Everything else in the submission sequence is covered in publishing to the App Store.
Check yours
What each store actually says about your submission
Tick what describes your next submission. What comes back is what the documentation says about it, including where it says nothing.
Nothing ticked. For an ordinary update with nothing unusual in it, both stores publish exactly one thing: Apple's goal, and Google's ceiling. Neither is about your app.
Is anything about an expedited review actually promised?
No, and there is no eligibility test either. Apple publishes one hard condition, and it is procedural rather than qualifying: only submissions that have already been sent to App Review can be expedited. Beyond that, App Review will evaluate your request and expedite the app's review as allowed by availability and demand. Read 17 October 2026. Availability and demand is a capacity condition. On a busy day a good case loses, and no document says otherwise.
The deeper gap is that the two first-party documents do not use the same words for what qualifies. The App Review Help page gives fixing a critical bug and timing your release to coincide with an event as examples of extenuating circumstances. The Review Guidelines, in their own paragraph on expedite requests, say instead that you can ask if you have a critical timing issue, and the string critical bug does not occur in the Guidelines at all. Neither phrase carries a definition, a threshold or a list of qualifying faults anywhere in Apple's documentation. What the Guidelines do add is a cost: ask only when you truly need it, and if Apple finds you abusing the system it may reject your requests going forward. That is the one firm statement in the whole area, and it is about losing the privilege, not earning it.
So an expedite request is a case made to a person, with no entitlement behind it and a quota you can burn. Which is why the lever worth building into your release process is the one that does not depend on Apple at all. An approved build does not have to reach everyone at once, and a phased release puts the rollout speed under your control even though the review speed never is.
What does Google publish instead, and why is it inverted?
A ceiling and no target. Play Console Help says processing can take a few hours or up to seven days, or longer in exceptional cases, as it depends on the review time that your app is subject to. On the publishing page the same ceiling appears twice, once as a note about certain developer accounts and once under standard publishing. There is no percentage, no average, no goal and no typical figure on either page. Read 17 October 2026. Where Apple tells you how often it is fast, Google tells you how slow it is allowed to be.
Google is also the store that uses the words service level agreement, which is the opposite of what people assume. It appears in one help answer, and only to locate the clock: the SLA or turnaround time for review time is counted from the last submitted change to an app. No number is attached to the SLA it names. The consequence is the useful part. Submit a change while other changes are in review and your app may be pushed to the back of the app review queue, with the publish control disabled until the review finishes. On Android, tidying up a release mid review costs you days rather than minutes.
One more thing Google documents that Apple does not, and it is buried. The main publishing page says only that for certain developer accounts Google will take more time to thoroughly review your app to help better protect users. It never says which accounts. The page on controlling when app changes are reviewed is where they are named: managed publishing is also useful for apps subject to extended review times, such as apps submitted by new developer accounts. If this is your first Android app, the seven day figure is your planning number, not the outside case. Google's own advice agrees: include a buffer period of at least a week between submitting your app and going live.
And there is no expedited request to ask for. The words expedited, priority and faster review do not occur on either page. What Google gives you in exchange is control over the publish step: managed publishing holds an approved change until you release it, so the review can finish quietly days before your launch date. That is a worse tool for an emergency and a better tool for a plan.
Google Play Console Help, control when app changes are reviewed and published, read 17 October 2026
Two stores, two opposite shapes of statement
| What is published | App Store | Google Play | Same on both |
|---|---|---|---|
| A published speed target | Yes. A goal of 50% under 24 hours, 90% under 48 | No target of any kind | No |
| A published maximum | None anywhere in App Review Help | Up to seven days, or longer in exceptional cases | No |
| The number appears in the review rules | No | No | Yes |
| Uses the words service level agreement | No | Yes | No |
| An expedited request is documented | Yes | No | No |
| What the clock runs from | Not documented | The last submitted change to the app | No |
| Who is documented as waiting longer | Complex submissions, paperwork checks, repeat rejections | Certain accounts, new developer accounts given as the example | No |
Read from Apple's App Review Help, the App Store Review Guidelines dated 16 October 2026, and Play Console Help, all on 17 October 2026.
Where this lands if a builder generated your app
The queue does not care who typed the code, but one thing does change: you are the one standing in it. App Store Review Guideline 4.2.6 says apps created from a commercialised template or app generation service are rejected unless they are submitted directly by the provider of the app's content. So no tool can submit on your behalf, which means no tool can shorten your review, request your expedite or answer a reviewer's question for you.
Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own, with two way GitHub sync so the code is never trapped. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It is $25 a month, with no free plan. What that changes about review timing is the bit before the queue: iterating on TestFlight and on an internal test track costs you no review at all, so the submission you eventually file is the one you already trust.
That matters because review time is cheap and round trips are expensive. A fast first pass is worth less than not needing a second one. The honest limit is that generating an app does not buy you a place at the front of either queue, and both stores reserve the right to look harder at something new. Budget the wait the way you budget what an app costs to maintain, as a recurring line rather than a launch surprise.
Questions people ask about app review speed
Apple publishes a goal, not a duration. The sentence, which appears on two App Review Help pages and nowhere else, reads: App Review works around the clock with the goal of reviewing at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. Read 17 October 2026. That is a statement about Apple's whole queue over some unstated period, not about your submission. One submission in ten is expected to take longer than two days, and Apple publishes no figure for how much longer that tail runs.
Promise the date you can keep
Tell people a launch week, not a launch hour. Submit with every document attached, fix every issue before you resubmit, and keep the release switch in your own hands. Then review speed stops being something you wait on.
Start building