The honest answer is that App Store review has no guaranteed time. Apple says it reviews 90% of submissions within 24 hours on average, but that is an average, not a promise, and in 2026 many developers saw waits of several days. If yours is taking longer than usual, it is usually the queue or your account rather than a problem with your build. The right moves are to check your metadata, avoid resubmitting, and request an expedited review only if you have a genuine emergency.
Short answer
Apple states that "on average, 90% of submissions are reviewed in less than 24 hours", per its App Review page, but that average spans everything from quick metadata updates to brand-new apps. Waiting for Review means your submission is queued; In Review means a reviewer is actively evaluating it. There is no service level, so treat any figure as an estimate. You can request an expedited review for a genuine emergency, resubmitting restarts the clock, and past several days without movement it is worth contacting Apple.
What is a normal App Store review time?
A normal review is a few hours to about 24 hours for most submissions, with 48 hours still common and longer possible. Apple's published figure, 90% within 24 hours on average, sets expectations but guarantees nothing, and it lumps together simple changes and complex new apps. The table below maps the statuses you will see to what is normal and when to worry.
| Status in App Store Connect | What it means | Typical time | Alarm signal |
|---|---|---|---|
| Waiting for Review | Queued for review | Hours to 48 hours | Over 3 to 4 days with no change |
| In Review | A reviewer is evaluating it | Minutes to a day | Over 48 hours in this state |
| Pending Developer Release | Approved, waiting for you | Final state, you decide | (none) |
| Rejected | Apple found an issue | Needs your action | Read the Resolution Center |
| Metadata Rejected | Metadata-only issue | Fix and reply | (none, usually quick) |
During February and March 2026, a broad slowdown pushed App Store waits to days or weeks for many developers, as documented on the Apple Developer Forums. In those windows, a long wait often reflects volume rather than a problem with your app, which is worth remembering before you assume something is wrong.
Why is your review taking so long?
Most delays come from your account and submission type, not code quality. The common drivers are Apple's queue volume, being the first submission of a new app, large changes that trigger a closer look, sensitive permissions like location or user data, and metadata problems such as an empty review note or missing export compliance. Submissions made just before high-volume windows, like the start of an iOS beta or the weeks around an Apple event, tend to queue longer.
There are also account-level factors. New accounts and accounts flagged for a closer look are reviewed more carefully, which adds time. And during a general backlog, even a simple app can sit for days, in which case uploading new versions does not help, because the bottleneck is the queue rather than your build. Separating these causes matters, because the fix for a slow queue is patience, while the fix for a metadata problem is a quick edit. A first submission of a brand-new app is also almost always slower than an update to an existing one, because Apple evaluates everything for the first time, from your privacy details to your age rating.
Can you expedite review?
Yes, Apple offers an expedited review request, but it is meant for genuine emergencies, not routine impatience. Legitimate cases include a critical bug affecting users in a live app, or a time-sensitive event tied to a fixed date. You request it through Apple's contact form, and if granted, your submission moves ahead in the queue. It is not guaranteed, and requesting it for every submission erodes your credibility for the times you truly need it.
Expedited review is not a cure for a normal wait. If you are within the typical range, or caught in a general slowdown, an expedited request is unlikely to help and may simply be declined. Save it for a real, explainable emergency, and describe the impact clearly and specifically when you ask, because a vague request is easy to turn down. One practical habit is to keep expedited requests rare, so that when you do submit one, your track record makes it more likely to be taken seriously.
Do resubmissions restart the clock?
Yes. Uploading a new build of the same version replaces the one in review and restarts the process, sending you to the back of the queue. Editing metadata on a submission that is Waiting for Review can also return it to the queue. Resubmit only when you have actually fixed something that would have caused a rejection, for example after reading a rejection reason in the Resolution Center.
The calmest approach is to leave the submission in place and wait within the normal range. Resubmitting to nudge the queue almost always makes it slower, because your position resets each time. Bundle real fixes into a single clean build rather than uploading several in quick succession, which only multiplies the restarts and delays you further.
What to do while you wait
Figure out how long you have waited and act on that, instead of resubmitting on reflex. The table below gives a clear route by situation.
| Your situation | What to do first | When to escalate |
|---|---|---|
| Under 48 hours | Wait, this is normal | Not yet |
| 2 to 7 days | Check metadata, review notes, export compliance | Prepare a case |
| Over 7 days, no change | Contact Apple with dates and screenshots | Immediately |
| Genuine, verifiable emergency | Request an expedited review | Right away, with justification |
| Status is Rejected | Read the reason in the Resolution Center and fix | Only if the reason looks wrong |
Before you escalate, confirm three things: that your export compliance information is complete, that your review notes explain how to test the app with a demo account if it requires a login, and that no other submission of the same app is blocking the process. These three resolve a large share of cases that look stuck but are really missing a detail on your side. If your app depends on a launch date, tell stakeholders early that the timeline is outside your control, and plan around the upper end of the normal range rather than the best case.
When to contact Apple
Contact Apple when you clearly pass the normal range, especially past several days with no movement. For a rejection, respond in the Resolution Center, the channel Apple reads for review cases. Include the app identifier, the exact submission date and time, and a screenshot of the status, so your case is not held up for missing information.
Keep expectations realistic. During the 2026 slowdown, developers reported slow responses to support and expedited requests. Escalating is the right move after several days, but it is not a guaranteed unblock, especially when the cause is a general backlog rather than a problem specific to your app. Document everything in case the case drags on and you need to follow up in an orderly way.
Where a pre-submission scan fits
A rejected build sends you back into the queue, so the fastest way to protect your timeline is to not waste a review cycle on a build that was going to be rejected. An embedded secret key, a permission with no justification, or an insecure network setting can cost you a full cycle, which hurts most when the queue is already slow.
A scanner like PTKD.com analyzes your built .ipa before you submit and returns a graded report mapped to OWASP MASVS, so you can fix what would trigger a rejection before it enters the queue. It is worth being clear about the limit: a scanner cannot speed up Apple's review, change your place in the queue, or replace a manual audit for high-risk or regulated apps. What it does is prevent the avoidable rejections that restart the wait, which matters most when review is already taking too long. In short, you cannot control the queue, but you can control whether your build gives a reviewer a reason to send it back.
What to take away
- App Store review has no guaranteed time; Apple averages 90% within 24 hours, but 2026 saw waits of several days.
- Delays usually come from the queue, the account, or the submission type, not your code.
- You can request an expedited review for a genuine emergency, but not to skip a normal wait.
- Resubmitting restarts the clock, so leave the build in place unless you fixed a real problem.
- Before you submit, scan the build with PTKD.com so an avoidable rejection does not cost you a full review cycle.
