How long can an App Store submission stay In Review?
In Review is not the same as Waiting for Review. A reviewer has started evaluating the submission, so the useful question shifts from queue capacity to whether the app is testable and understandable.
Apple does not publish a guaranteed maximum for the In Review state. Its broad review-time statistic is not a timer for an individual submission. Keep the backend and demo account working, monitor App Store Connect messages, and investigate reviewer-access or submission-item dependencies before assuming the process is stuck.
Start a new clock when the status changes
The Submitted-to-In Review interval measures queue wait. The In Review-to-decision interval measures active review. Combining them produces a total duration but hides which part you can influence.
Apple's status reference confirms only that review is underway. It does not promise continuous hands-on testing or reveal whether the reviewer is awaiting internal consultation. Record the transition time and resist comparing it with a friend's total submission time.
Protect the reviewer's test path while review is active
- Keep production or review backends online; do not deploy a breaking schema change mid-review.
- Test the supplied credentials from a clean device and outside your office network.
- Remove one-time-password, geo, VPN, invitation, and allow-list barriers for the review account.
- Make sample content available so the reviewer can reach the feature described in the metadata.
- Verify submitted In-App Purchases load in the exact build under review.
Guideline 2.1 asks for full access, including a demo account or a fully featured demo mode, and requires backend services to remain live during review.
Treat a question as a test interruption, not a rejection
Watch the App Review section and the account email for questions. A reviewer may need a route to a hidden feature, an explanation of a business model, or working credentials. Reply with the shortest path to verification: numbered taps, expected result, and any account role needed.
If the requested information exposes an actual defect, acknowledge it and decide whether a new build is necessary. If the feature works but the path was unclear, clarify it in the message and improve Review Notes on the next submission.
To test [feature]: 1. Sign in with the review account in App Review Information. 2. Open [tab] and tap [control]. 3. Choose [sample item]. Expected result: [observable behavior]. No purchase or external hardware is required.
Inspect the whole submission when one item lingers
A submission can contain multiple items, and Apple requires all included items to be accepted before the submission completes. Check item-level states rather than treating the app-version badge as the only source of truth.
In-App Purchases and subscriptions follow their own submission process, but their readiness can still affect what the reviewer can exercise in your build. Confirm product status, localization, pricing, availability, and the product identifiers used by the binary.
Escalate an outlier without disrupting a healthy review
Contact support when you have checked access, messages, and item states and the active-review duration is materially outside comparable cases. Include the In Review transition time and any messages already answered. Do not cancel unless you know the current build cannot pass or Apple directs you to replace it.
For a live critical bug or a directly associated event, evaluate an expedited request. The request should explain urgency, not merely restate that the status has lasted longer than expected.
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.
Separate the two review clocks
See how AppReviewReady measures queue wait and active review independently.
Open the tool