Apple currently says that, on average, 90% of submissions are reviewed in less than 24 hours. That is an aggregate statement, not a deadline or guarantee for your app. An incomplete, complex, or unusual submission can take longer, and the clock you care about depends on whether the version is Ready for Review, Waiting for Review, In Review, or waiting for your action.
Before contacting Apple, confirm that the draft was actually submitted, check App Review messages, and verify that the demo account and backend are still available.
The short version
- Ready for Review is not in Apple’s queue; you must still submit the draft.
- Waiting for Review means Apple received it but has not started.
- Apple’s “90% under 24 hours” statement is not a promise for one submission.
- Request expedited review only for the extenuating circumstances Apple describes.
Start with the exact status
Review timing starts with a submission Apple has received. If the version is Ready for Review, it sits in a draft and has not been sent. Open the draft and select Submit for Review.
If it is Waiting for Review, Apple has received the submission but has not started reviewing it. In Review means review is underway. Unresolved Issues or Developer Action Needed means the next delay may belong to your response, correction, or access path rather than the queue.
Apple’s App and submission statuses page is the current source for each label. Record the version, build, status, and observed time before escalating.
The guide to App Store review statuses explains the action attached to each state.
Interpret Apple’s timing statement correctly
On its current App Review page, Apple says: “On average, 90% of submissions are reviewed in less than 24 hours.” Apple also says incomplete submissions may be delayed or may not pass.
There are three important qualifiers:
- On average: the statement describes a broad set of submissions.
- 90%: some submissions fall outside that group.
- Reviewed: it does not promise your chosen release date or a successful outcome.
Do not publish an internal launch plan that treats 24 hours as a service-level agreement. Keep room for review, questions, a corrected build, and distribution processing.
Do not replace Apple’s current figure with a community average unless you clearly label and source it. AppRejectKit does not publish an independent review-time dataset.
Why a review can take longer
A longer review does not reveal the reviewer’s motive. Apple publicly notes that incomplete submissions can be delayed. Other release characteristics can require more review work, but you should not claim a hidden reason without an Apple message.
Check the factors you can verify:
- all required metadata is complete and accurate;
- public URLs are functional;
- the selected build launches and reaches production services;
- demo credentials work from a clean state;
- non-obvious features and purchases are explained;
- related subscriptions, in-app purchases, or events are complete;
- Apple has not asked for additional information;
- no agreement or compliance prompt is blocking the item.
Apple’s App Review guidance advises giving full access and detailed explanations for non-obvious features. Fixing those gaps improves reviewability, but it does not create a guaranteed timeline.
What to do while Waiting for Review
Use the waiting period to preserve the submitted environment, not to make speculative changes.
Monitor:
- authentication and core service health;
- demo account validity;
- expiring certificates or test data relevant to the route;
- App Store Connect notifications and email;
- the status of every item included in the submission.
Avoid changing feature flags, account roles, product identifiers, or backend behavior that the reviewer needs. If you discover a material defect, document it and decide whether to remove the submission, fix the cause, and send a tested replacement.
Do not upload repeated builds merely because the queue feels slow. A new upload does not repair a complete submission that is simply waiting, and replacing the selected build creates a new release candidate to test.
When normal support makes sense
Contact Apple Developer Support when you have a specific App Store Connect or submission problem that documentation and status messages do not resolve. Examples include an interface block, a status that cannot progress because of an unexplained system issue, or a technical account problem.
Prepare a concise case:
- app name and Apple ID;
- platform version and build number;
- current status;
- time the submission entered that status;
- exact error or missing action;
- steps already taken;
- screenshots that show the App Store Connect problem without exposing secrets.
“Please approve my app” is not a diagnostic support request. Ask the narrow question you need answered.
Apple’s contact pages may require sign-in, so use the support route from your developer account. Keep any case number with the submission log.
When expedited review fits
Apple says you can request an expedited review for extenuating circumstances, including a critical bug fix or an event you are directly associated with. This is a request, not an entitlement, and Apple decides whether it can accommodate it.
For a critical bug fix, Apple asks for reproduction steps for the problem in the current App Store version. For an event, explain the event, your association, and the timing.
Do not manufacture urgency or submit repeated requests. A marketing date you chose does not automatically meet Apple’s examples. Supply the facts and keep a fallback plan.
If the app has an unresolved issue, answer requests for information and correct known gaps before using escalation as a substitute for readiness.
Plan a launch without guessing the review time
Build the launch plan around states rather than one date:
| State | Team action |
|---|---|
| Draft | Complete and verify the full submission |
| Waiting for Review | Preserve access and monitor |
| In Review | Keep services stable and watch messages |
| Issue returned | Reproduce, choose reply/metadata/build/appeal |
| Accepted, manual release | Run release-day checks, then release |
| Ready for Distribution | Verify availability and product page |
If timing matters, submit with enough buffer to absorb a question or corrected build. Manual release can separate approval from your public launch action, though availability and processing still require verification.
The first iOS submission guide covers release method as part of the full submission chain.
Decide whether to wait or act
Use observed evidence:
- Ready for Review: act now and submit the draft.
- Waiting for Review, no message, services healthy: continue monitoring.
- In Review, no message: keep the review environment stable.
- Apple requested information: respond directly with the missing facts.
- You found a code defect: remove if appropriate, fix, test, and submit a new build.
- Critical live bug or directly associated event: consider an expedited review request with evidence.
- Unexplained technical block: open a focused support case.
Elapsed time alone does not tell you to upload a build, appeal, or change metadata.
FAQ about App Store review time
Is App Store review guaranteed within 24 hours?
No. Apple’s current statement is that 90% of submissions are reviewed in less than 24 hours on average. It is not a guarantee for an individual submission.
When does the review wait begin?
The meaningful queue state is Waiting for Review, after you select Submit for Review. Ready for Review is still a draft.
Should I contact Apple after 24 hours?
Not automatically. Check the exact status, messages, and submission health first. Contact support when you have a specific issue or unexplained block.
Can I request expedited review for a launch date?
Apple describes expedited review for extenuating circumstances such as a critical bug fix or an event you are directly associated with. Explain the facts; Apple decides whether to accommodate the request.
Does removing the app from review make it faster?
No. Remove it when you need to correct a real issue, not as a queue tactic. A changed build must be retested and submitted again.
Conclusion
Use Apple’s published timing as context, not a countdown. Status, messages, and submission completeness determine whether you should wait, reply, fix, or contact support.
Check your version and build in App Store Connect now. If the status is Ready for Review, finish the submission. If Apple has received it, preserve access and act only on evidence.