Measure three clocks, not one
Queue wait begins when the submission enters “Waiting for Review” and ends when it becomes “In Review.” This is the clearest signal of current capacity and prioritization.
Active review begins at “In Review” and ends at a decision. Login flows, IAP, sensitive categories, entitlements, and unclear reviewer access can add work here.
Decision-loop time includes rejection, fixes, replies, and resubmissions. Unlike the queue, much of this clock can be reduced before you submit.
What counts as a normal App Store review time?
Apple currently states that, on average, 90% of submissions are reviewed in less than 24 hours. That figure combines new apps, updates, different platforms, and established developer accounts. Treat it as a platform-wide reference—not a promise for a first app.
Canceling removes the current submission. Only resubmit when you have a real change or Apple asks you to do so.
Why first submissions need their own baseline
A first submission introduces both a new binary and a new product context. The reviewer may need to understand login, business model, data collection, subscriptions, and whether the experience is meaningfully complete. Routine updates from mature teams are a poor benchmark for that situation.
AppReviewReady therefore asks whether a timeline is a new app or an update, and whether it includes login or IAP. Webhook verification will later add higher-confidence status timestamps without requiring an App Store Connect API key.
When waiting becomes an action problem
- Check App Store Connect for agreements, compliance, IAP, and metadata actions.
- Confirm the build and every submitted item still show a review state.
- Use Apple's contact path if your wait is a clear outlier for comparable submissions.
- Request expedited review only for a genuine critical or time-sensitive case.
- Do not upload repeated builds unless something material changed.