How long does App Store review take?

Apple quotes roughly 24 hours and most submissions do move that fast, but the queue is not a guarantee. One of my apps sat 15 days at Waiting for Review, then went to In Review and was approved the same day. The long part was queue latency, not scrutiny — once a reviewer actually opened it, the whole session took nine minutes.

My app has been stuck on Waiting for Review for two weeks. Is something wrong?

Almost certainly not. Waiting for Review means no reviewer has opened your app yet — it is queue position, not scrutiny. One of mine sat there 15 days with nothing wrong with it, then approved the same day someone picked it up. You can confirm this rather than hope: the App Store Connect API will tell you whether review has started.

Should I resubmit if my app is stuck in Waiting for Review?

No. Resubmitting puts you at the back of the queue, so the single most common reaction to a long wait is the one that makes the wait longer. The same applies to swapping the build or rewriting review notes — all of it resets your position. Check whether review has actually started first; if the state is still WAITING_FOR_REVIEW, there is nothing to fix because nobody has looked.

How can I tell if App Store review has actually started?

Query the App Store Connect API: GET /v1/reviewSubmissions?filter[app]={appId} and read state. It moves WAITING_FOR_REVIEW to IN_REVIEW. While it still reads WAITING_FOR_REVIEW, no reviewer has opened your app at all — so silence means queue latency, not a problem with your build, your demo login, or anything you did.

What IP addresses does App Store review come from?

Both 17.0.0.0/8, which everyone knows is Apple, and AS714 139.178.128.0/17, which is much less well known. An absence of 17.x traffic is not an absence of Apple. The 139.178 range is Apple corporate and engineering, not iCloud Private Relay — you can verify that against Apple's published Private Relay egress list, which contains no 139.178 ranges at all.

Can I deploy server-side fixes while my app is in review?

Yes, and they apply to the binary under review, because the binary talks to your live API. I shipped two fixes mid-review: an endpoint returning 500 became a clean 403, and a token grace period went out about eight minutes before the reviewer's access token would have expired and turned their video black. The corollary is that you should deploy nothing risky while a reviewer is in your app.

Why can I not just watch my logs to see if Apple is reviewing?

Because TestFlight Beta App Review and App Store review are different tracks and both come from Apple's network. Log traffic alone cannot tell you which one you are seeing. The API can.

App Stuck on 'Waiting for Review'? How to Tell If It Started

Fifteen days in the queue, then approved the same day it was opened. Here is how to tell whether review has actually started, where Apple reviews from, and the nine minutes I watched happen in my server logs.

On August 10, 2026 I submitted Restoria for App Store review. It sat at Waiting for Review for fifteen days.

Apple's norm is around twenty-four hours. Two weeks of silence is exactly long enough to start rewriting review notes, second-guessing a demo login, and wondering whether something about the build offended a static analyzer.

None of that was happening. Nobody had opened it.

On August 25, 2026 a reviewer picked it up, spent nine minutes in the app, and approved it the same day.

Stuck on "Waiting for Review" for days? Do not resubmit

If you have landed here mid-wait, that is the one thing worth saying first. Resubmitting sends you to the back of the queue. So does swapping the build, and so does editing the version in ways that require re-approval. The most common reaction to a long wait is the thing that makes the wait longer.

Before changing anything, find out whether a reviewer has opened your app at all. Usually nobody has.

The question you actually want answered

App Store Connect's web UI shows you a status. What it does not make obvious is the difference between queued and being looked at — and those are completely different situations that call for completely different behavior.

The API answers it directly:

GET https://api.appstoreconnect.apple.com/v1/reviewSubmissions?filter[app]={appId}

Read state. It moves WAITING_FOR_REVIEW → IN_REVIEW.

While it still says WAITING_FOR_REVIEW, no human has opened your app. Not "a reviewer is being thorough". Not "something looks suspicious". Nobody has started. Silence is queue latency.

That single distinction is worth wiring up, because it converts two weeks of speculation into a yes or no. Everything you would otherwise be tempted to change — resubmitting, rewriting review notes, swapping the build — resets your place in that queue and makes the wait longer.

Two more endpoints earn their keep:

GET /v1/apps/{appId}/appStoreVersions → appStoreState, the version's own status.
appStoreReviewDetail returns the demo account credentials Apple actually holds. If you suspect a reviewer is locked out, check what they were given rather than guessing. Stale review notes are a real failure mode and this is how you rule it in or out.

Authentication is an ES256 JWT signed with an App Store Connect API key. If the machine has no JWT library handy, openssl and your language's standard library are enough — it is a three-field header and a short claims set.

Where Apple reviews from

Everyone knows 17.0.0.0/8 is Apple. Most people stop there, and that is how you convince yourself Apple has not touched your app.

App Store review traffic also comes from AS714, 139.178.128.0/17. If your log filter only watches 17.x, you will see nothing and conclude nothing is happening.

It is worth being precise about what 139.178 is, because the obvious guess is wrong. It is Apple corporate and engineering — not iCloud Private Relay. You can verify that yourself: Apple publishes the Private Relay egress ranges at mask-api.icloud.com/egress-ip-ranges.csv, and there are zero 139.178 ranges in it.

One more trap. TestFlight Beta App Review and App Store review are different tracks, and both originate from Apple's network. Logs alone cannot tell you which one you are watching. That is precisely why the API question above matters — it distinguishes them and your access log cannot.

The nine minutes

Here is the reviewer session, August 25, 2026, 18:46–18:55 UTC, from 17.222.114.234:

GET  /app/version          version check on launch
POST /auth/apple           signed in with Sign in with Apple
     subscribe             hit the paywall
     AI Quick Session      used the headline feature
     start a session       ...and actually ran one
     stream video          206 range requests, so they watched it
GET  /users/blocks         the 1.2 user-generated-content checklist
     profile edit          changed something on their account

Zero non-2xx responses across the entire session.

Three things in that trace are worth more than the timing.

They did not use the demo login. I supplied one. They signed in with Apple instead. If your app only works properly for the demo account — seeded data, a bypassed paywall, a special case somewhere — a reviewer taking the front door will find whatever that special case was hiding.

They went straight to the money. Subscribe, then the flagship feature, then a real session end to end. Not a tour of settings screens. Whatever your app is for is what gets exercised.

GET /users/blocks is Guideline 1.2. If your app has user-generated content, Apple requires a way to block users and filter objectionable content. That request is a reviewer ticking a specific box. Knowing which endpoint corresponds to which guideline tells you exactly what they are checking as they check it.

You can fix things while they are in the app

This is the part that changes how you behave during review, and I want to be careful about how I put it.

The binary under review talks to your live API. Server-side changes apply to it immediately. The app Apple is testing today is your production backend, whatever you deployed five minutes ago.

I used that twice during those nine minutes:

A delete-account endpoint was returning 500. That is Guideline 5.1.1(v) territory — account deletion has to work. It became a clean 403 mid-review.
A stream-token grace period shipped roughly eight minutes before the reviewer's access token would have expired and turned their video black.

The obvious corollary is the more important one. Deploy nothing risky while a reviewer is in your app. The same mechanism that let me fix two things would have let me break everything, and a reviewer hitting a fresh 500 does not know it was a deploy. Keep the API surface green and sit on your hands.

It approved with a known crash

Worth recording honestly, because the internet's model of App Store review is more mystical than the reality.

The reviewer hit a WatchdogTermination about a second after the library grid loaded, on an iPad running iOS 26.6. I have two independent confirmations: a crash report tied to their session, and a second cold version check, which is what a relaunch looks like.

My target device family includes iPad, so iPad is a supported device and that counts against Guideline 2.1.

It approved anyway.

Draw the right conclusion from that. Not "crashes are fine" — it is getting fixed before the next submission. The lesson is that review is a human spending a few minutes forming a judgment, not an exhaustive audit, and the variance runs in both directions. Plenty of apps are rejected for less.

What I would set up before the next submission

A one-command review-state check. reviewSubmissions.state, printed. It is the difference between knowing and guessing, and guessing costs you resubmissions.
A log filter covering both ranges — 17.0.0.0/8 and 139.178.128.0/17 — so a reviewer session is visible while it happens rather than reconstructed afterward.
An alert on non-2xx responses during any window where review might start. A 500 a reviewer sees is a rejection; a 500 you see first is a deploy.
A deploy freeze from submission until the state flips, or at minimum a rule that nothing touching auth, payment or the main flow goes out unattended.

The short version

Fifteen days of silence meant nothing had happened. Nine minutes of attention decided it. The API will tell you which of those you are in, and your access log will show you the second one as it happens — if you are watching the right two IP ranges.