An App Store submission stuck on "Waiting for Review" too long usually just means it is sitting in the queue during a busy period, not that anything is wrong. "Waiting for Review" is the queue state before a reviewer picks up your app, and most submissions move out of it within 24 to 48 hours, since Apple reviews the majority within a day. If you have a genuine, time-sensitive deadline, you can request an expedited review to move up the queue. What you should not do is cancel and resubmit out of impatience, because that sends you to the back of the queue and lengthens the wait. Contact App Review only after you clearly pass 48 hours.
Short answer
A long "Waiting for Review" is almost always queue time, so the default is to wait. Per Apple's App Review page, most submissions are reviewed within 24 hours, and "Waiting for Review" is the state before a reviewer starts, so it is where the waiting happens. For a real, dated deadline, request an expedited review to move up. Do not cancel and resubmit to try to speed it up, since that restarts you at the back of the queue and makes the wait longer. If you clearly pass 48 hours with no movement, contact the App Review team. Otherwise, waiting through the normal window is the correct action.
What "Waiting for Review" means
"Waiting for Review" means your submission is in the queue but no reviewer has started evaluating it yet. It is the state between submitting your app and a reviewer picking it up, so nothing is actively happening beyond your app waiting its turn. This is different from "In Review", which means a reviewer has begun the active evaluation.
The distinction matters for how you interpret a long wait. Because most of the total review time is spent waiting in the queue rather than being actively reviewed, "Waiting for Review" is normally the longest phase, and a submission can sit there for a while before moving quickly through "In Review" to a decision. So a long "Waiting for Review" is usually just queue time, not a sign that your app has a problem.
How long is normal?
For "Waiting for Review", up to 24 to 48 hours is normal. Apple reviews most submissions within about a day, and since the queue is where the time is spent, a submission waiting for a reviewer for a day or two is well within the routine range. A first submission or a busy period can push it toward the longer end without anything being wrong.
Beyond about 48 hours with no movement, you are outside the typical window, and it becomes reasonable to consider contacting support. Apple does not promise a fixed time, so treat these figures as averages rather than guarantees. The practical marker is to note when your app entered the queue, so you can tell a normal wait from a genuine over-run rather than judging by how long it feels.
Why it can take too long
A long "Waiting for Review" is most often a queue backlog rather than an issue with your app. During busy periods, such as before major seasonal releases or after a platform change, more submissions are in the queue, so everyone waits longer for a reviewer to become available. This affects all developers, not just you, and there is nothing in your app to fix.
Other factors can lengthen the wait too. A first submission tends to wait longer than an update to an established app, and an app in a sensitive category may take more time once it is picked up. But while it is still in "Waiting for Review", the cause is almost always the queue, which is why the right response is usually patience rather than action, unless you have a genuine deadline.
Should you request an expedited review?
If you have a genuine, time-sensitive reason, yes. An expedited review request asks Apple to move your submission up the queue, which is exactly what helps when your app is stuck in "Waiting for Review" and you have a real deadline, such as a dated event or a critical fix for current users. It is the legitimate way to shorten a queue wait.
Use it sparingly and honestly, though. Expedited review is meant for genuinely urgent cases, not ordinary impatience, and overusing it can lead Apple to decline future requests. So request an expedite when the timing truly matters and you can explain why, and otherwise let the normal queue run. An expedite is the right tool for a real deadline and the wrong tool for simply wanting it faster.
Should you cancel and resubmit?
No, not to speed it up. Cancelling a submission that is waiting in the queue and resubmitting does not move you forward; it sends you to the back of the queue, so your wait starts over and gets longer. Cancelling out of impatience is one of the most common ways developers accidentally lengthen their own review time.
The only good reason to cancel is to fix a real problem in the build before it is reviewed, accepting that the new submission re-enters the queue from the back. If the build is fine and simply waiting, leave it in place. When you need faster review, the right lever is an expedited request, not a cancel-and-resubmit, which only resets the clock you are trying to beat.
When to contact support
Contact the App Review team when your submission has clearly been in "Waiting for Review" beyond about 48 hours with no movement and no obvious explanation. Use Apple's contact form for App Review, including your app name, the build, and when it entered the queue, to ask about a review taking longer than expected. This keeps your place in the queue rather than restarting it.
Keep expectations realistic. Contacting support after a genuine over-run is reasonable, but it does not guarantee an immediate result, especially during a backlog, and developers report longer waits at busy times, as discussed in the Apple Developer Forums. Reaching out is the right move once you are past the normal window, and it is strictly better than cancelling, which would only send you to the back of the line.
Decision table
The right action depends on how long it has been and whether you have a deadline. The table below turns that into a simple decision.
| Situation | Best action |
|---|---|
| Under 48 hours in the queue | Wait |
| A genuine, dated deadline | Request an expedited review |
| Over 48 hours with no movement | Contact the App Review team |
| A real problem in the build | Cancel and resubmit, accepting the queue restart |
| Simple impatience | Do not cancel; wait |
Read the table before acting, since most situations, a wait under 48 hours, fall into the first row and call for patience. Only a genuine deadline warrants an expedite, and only a real over-run warrants contacting support.
Checklist
A short sequence keeps a queue wait from getting worse. The checklist below covers it.
| Check | Action | Done? |
|---|---|---|
| Track the time | Note when the app entered "Waiting for Review" | [ ] |
| Do not cancel | Avoid restarting the queue out of impatience | [ ] |
| Expedite if urgent | Request an expedited review for a real deadline | [ ] |
| Contact after 48 hours | Reach App Review rather than cancelling | [ ] |
| Submit a clean build | Scan and fix issues before submitting | [ ] |
The two that save the most time are not cancelling out of impatience and using an expedited request for a genuine deadline. Track when the app entered the queue, wait through the normal window, and escalate properly if it truly runs long.
Scan before you submit
Some submissions that clear the queue then get rejected once reviewed, and a security or privacy issue is a common cause. Because a rejection means fixing the problem and re-entering the queue from the back, catching those issues before you submit avoids the whole extra wait.
A scanner like PTKD.com analyzes your .ipa and reports findings ordered by severity and mapped to OWASP MASVS, so you catch issues like unjustified permissions, cleartext traffic, or embedded secrets before a reviewer does. To be clear about the boundary: PTKD does not move you up the queue or speed up a review. It reduces the chance that a long wait ends in a rejection that sends you back to the end of the line.
What to take away
- "Waiting for Review" is the queue state before a reviewer starts, and it is normally the longest phase, so a long wait is usually just queue time.
- Up to 24 to 48 hours is normal; a long wait is most often a queue backlog, not a problem with your app.
- Request an expedited review only for a genuine, dated deadline, and use it sparingly since overuse can lead Apple to decline future requests.
- Do not cancel and resubmit to speed it up, since that restarts you at the back of the queue; cancel only to fix a real build problem.
- Contact App Review after about 48 hours, and scan your build with PTKD.com so a long wait does not end in a preventable rejection.
