An app stuck in "In Review" is usually just taking longer than average rather than being truly stuck, and the worst response is often to cancel it, which sends you back to the queue. Reviewers do not read your source code line by line, because they do not have your source; they test the running app against the guidelines, checking behavior, functionality, and metadata. If your app has been In Review well past 48 hours with no change, the right move is to contact the App Review team, not to cancel and resubmit. Cancel only when you genuinely need to fix a problem in the binary.
Short answer
A long "In Review" is normally extra time, not a broken submission, so the default is to wait, not cancel. Per Apple's App Review page, most submissions are reviewed within 24 hours, but some take longer, especially complex or sensitive apps. Reviewers test the running app against the guidelines; they do not read your code line by line, since they do not have it. Cancelling to resubmit restarts the review from the back of the queue, so it usually lengthens the wait. If you clearly pass 48 hours with no change, contact the App Review team rather than cancelling. Cancel only when you must fix a real problem in the build.
Why an app gets stuck In Review
Most apps that seem stuck are simply taking longer than the typical day, which happens for understandable reasons. A first submission, an app in a sensitive category like finance or health, or one requesting notable permissions gets a closer look, and a general backlog during busy periods slows everything. None of these mean anything is wrong; they mean the review is taking its time.
Less often, a review pauses because the reviewer needs something they cannot get, such as a demo account that does not work or a feature they cannot reach. In that case the review can stall until the problem is resolved, which is why a working demo login and a fully functional build matter. So a long In Review is usually normal extra time, occasionally a sign the reviewer is blocked, and rarely anything you fix by cancelling.
Do reviewers read your code line by line?
No. Apple reviewers do not have your source code, so they cannot and do not read it line by line. What they do is run and test the built app, evaluating its behavior, functionality, and metadata against the App Store Review Guidelines. They interact with the app the way a user would, checking that it works, does what it claims, and does not violate the rules.
This matters for how you think about a stuck review. The reviewer is spending time using your app, not auditing your code, so what slows or blocks them is a functional or policy issue they encounter, not something buried in your implementation. It also means the way to help a review go smoothly is to ensure the app is complete and usable, with working demo access, rather than worrying about how your code reads.
Should you cancel the submission?
Usually not. Cancelling a submission that is simply taking longer than average does not speed anything up; it removes your place in line and, when you resubmit, starts the review over from the back of the queue. So cancelling an in-progress review out of impatience typically makes your total wait longer, not shorter, which is the opposite of what you want.
There is one good reason to cancel: you discover a real problem in the build that you need to fix, such as a serious bug or a change you must make before it goes live. In that case cancelling to submit a corrected binary is appropriate, accepting that review restarts. But if the build is fine and simply waiting, leave it in review, because pulling it back only resets the clock.
What to do instead of cancelling
Instead of cancelling, wait through the normal window and prepare rather than react. Confirm your demo credentials work and that the reviewer can reach every feature, since a blocked reviewer is one real cause of a stall you can address without cancelling. Note when the app entered In Review so you can judge whether it has genuinely exceeded the typical range.
If you have a legitimate deadline, the right tool is an expedited review request, not a cancellation. Expedited review asks Apple to prioritize a time-sensitive submission, which is designed for exactly this situation and does not throw away your place the way cancelling does. So the productive alternatives are to wait, to ensure the app is fully testable, and to escalate through the proper channel if the timing truly matters.
When to contact App Review
Contact the App Review team when your app has clearly been In Review past about 48 hours with no change and none of the ordinary explanations obviously apply. Use Apple's contact form for App Review to ask about a review taking longer than expected, including your app name, the build, and when it entered review. This is the correct escalation, and it keeps your submission in place rather than restarting it.
Keep expectations realistic. Contacting App Review is reasonable after a genuine over-run, but it does not guarantee an instant result, particularly during a backlog, and developers report longer waits at busy times, as discussed in the Apple Developer Forums. The point is that 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 back to the queue.
Cancel, wait, or escalate?
The right action depends on how long it has been and whether the build needs a change. The table below turns that into a simple decision.
| Situation | Best action |
|---|---|
| In Review under 48 hours | Wait |
| A real problem in the build | Cancel and resubmit with the fix |
| Over 48 hours with no change | Contact App Review, do not cancel |
| A genuine, dated deadline | Request an expedited review |
| Rejected | Fix it per the Resolution Center |
Read the table against your case before acting. Only two rows call for cancelling or escalating; the most common situation, a review simply taking a while under 48 hours, calls for patience rather than any action at all.
Checklist
A short sequence keeps you from making a long review worse. The checklist below covers it.
| Check | Action | Done? |
|---|---|---|
| Track the time | Note when the app entered In Review | [ ] |
| Do not cancel impulsively | Avoid restarting the queue over impatience | [ ] |
| Demo works | Confirm the reviewer can access and use the app | [ ] |
| Contact after 48 hours | Reach App Review rather than cancelling | [ ] |
| Cancel only to fix | Cancel solely to submit a real binary fix | [ ] |
The two that save the most time are not cancelling impulsively and confirming the demo works, since a needless cancellation resets the clock and a broken demo is a real cause of a stall. Wait through the normal window, keep the app fully testable, and escalate properly if it truly runs long.
Scan before you submit
Some stuck reviews end in a rejection rather than an approval, and a security or privacy issue is a common cause of that. Because a rejection means fixing the problem and going through review again, catching those issues before you submit saves the whole extra cycle.
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 speed up a review or change its status. It reduces the chance that a review which felt stuck ends in a rejection you could have prevented.
What to take away
- A long "In Review" is usually just extra time, not a broken submission, so the default is to wait rather than cancel.
- Reviewers do not read your code line by line; they test the running app against the guidelines, so a working, complete build matters.
- Cancelling to resubmit restarts the review from the back of the queue, so cancel only when you must fix a real problem in the build.
- If you pass about 48 hours with no change, contact the App Review team, and use expedited review for a genuine deadline, rather than cancelling.
- Scan your build with PTKD.com before submitting so a slow review does not end in a preventable rejection.
