New app vs. update: compare App Store review time correctly
Apple does not promise that updates move faster than new apps. A useful comparison controls for what is being reviewed instead of turning anecdotes into a rule.
Use separate baselines for new apps and updates, but do not assume either receives priority. Compare the same platform, recent submission window, queue phase, active-review phase, login requirements, purchases, and major feature changes. Apple explicitly notes that submissions may not be reviewed in submission order.
There is no published new-app or update service level
Apple publishes a broad statement about the share of submissions reviewed within a day, but it does not break that statement into a guaranteed deadline for first releases and routine updates. Apple's submission help also says review order may differ from submission order.
That makes a single pair of timelines weak evidence. A six-hour update and a two-day first app may differ because of arrival time, platform, included items, app complexity, or reviewer access—not necessarily because Apple labels one an update.
Build cohorts before calculating a median
- Separate new apps from updates and keep platforms distinct.
- Use a recent rolling window so an old queue environment does not dominate the result.
- Tag login, subscriptions, In-App Purchases, regulated categories, and special entitlements.
- Split routine bug fixes from updates that introduce a new business model or substantial feature set.
- Publish sample size beside every median and suppress the number when the cohort is too small.
Compare three durations instead of one headline
Queue wait answers how long the submission remained Waiting for Review. Active review answers how long it stayed In Review before a decision. Decision-loop time captures rejections, developer responses, replacement builds, and resubmissions.
An established app may enter review quickly but spend longer in a complex active review after adding subscriptions. A first app may wait longer yet pass in one short session because the reviewer path is excellent. Total duration alone cannot explain either outcome.
Plan releases from the risk you control
- Choose the desired public date and work backward with a buffer rather than treating Apple's broad statistic as a deadline.
- For a new app, rehearse the entire review journey because no prior approved version establishes context.
- For an update, identify what changed in permissions, payments, account behavior, content, or hardware requirements.
- Use manual release or a scheduled release option when approval timing should not immediately trigger availability.
Use language your dataset can support
A defensible result sounds like: ‘In our last-30-day sample, routine updates had a lower median queue wait than new apps, with these sample sizes and filters.’ It does not sound like: ‘Apple always approves updates faster.’
Keep the observation date, inclusion rules, median, long-tail percentile, and count visible. When the sample is small, show that the baseline is forming instead of replacing missing evidence with precision-looking estimates.
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Read our queue-index methodology
See the thresholds, segmentation, and robust statistics used for AppReviewReady data.
Open the tool