"In Review": what Apple is actually doing to your app

In Review means a reviewer has your submission open. Somebody at Apple has taken it out of the queue and is working on it right now, or has it assigned and will be shortly.

This is the state you wanted to reach. It is also the state where the version is most thoroughly locked.

What is happening

Apple does not publish a step-by-step account of what a reviewer does, so anything precise you read about it is inference. What can be said from observable behaviour:

• Your binary is installed and run on real devices.
• Your metadata is read, description, screenshots, keywords, age rating, what's new.
• Automated checks have already run, mostly at upload time. INVALID_BINARY and its relatives happen during processing, before review.
• If you supplied review notes and a demo account, the reviewer uses them. If your demo account does not work, this is where that surfaces, commonly as a rejection asking for working credentials.

Reviewers open the app. If the first screen is a login wall with no way through, that is where the review ends.

How long it lasts

Shorter than the queue, usually. IN_REVIEW is often measured in hours rather than days, but that is aggregate developer experience, not a commitment from Apple, and a review that raises a question can stay open much longer.

A long IN_REVIEW is not automatically bad news. It sometimes means the reviewer escalated a question internally, which is slower than a straight approve or reject in either direction.

What you can change

Nothing on this version. Description, keywords, screenshots, the build, the version number, all locked while the state is IN_REVIEW.

If you have realised something is wrong, your only lever is to withdraw the submission yourself. That moves the version to DEVELOPER_REJECTED, unlocks it for editing, and costs you your place in the queue. Whether that trade is worth it depends entirely on whether the thing you spotted would have been rejected anyway.

What you can still change:

• Price and availability
• Anything on a separate version in PREPARE_FOR_SUBMISSION
• Your backend, which matters more than people realise. If your API is down while a reviewer is opening your app, you will be rejected for a crash or a blank screen that has nothing to do with your build.

That last point deserves a rule: do not deploy risky backend changes while a submission is In Review. The reviewer is a real user hitting your real servers.

Where it goes next

From IN_REVIEW, exactly four things can happen.

Approved with manual release → PENDING_DEVELOPER_RELEASE. It is through. Nothing is live until you press release.

Approved with automatic release → READY_FOR_SALE. Live, sometimes within minutes. Store propagation across regions takes a while longer, so "live" and "visible to everyone searching" are not the same moment.

Rejected on the binary or on behaviour → REJECTED. Usually needs a new build.

Rejected on text or images only → METADATA_REJECTED. Fix the listing, resubmit, no new build.

There is a fifth thing that is not a state change: Apple messages you with a question. The version stays IN_REVIEW while you reply. Answer it in Resolution Center, and answer the actual question, briefly.

If you get a message rather than a verdict

Reply quickly and specifically. A reviewer asking "which of these features requires the location permission?" wants a sentence, a screen name and a reason. Not a paragraph of context.

If the answer is that they have misread the app, say where to look, screen by screen, in the order they would tap. Reviewers are working through a queue; the response that requires the least reconstruction gets resolved fastest.

Reading the state rather than waiting for the email

Apple emails you on the outcome, not on entering review. The transition from WAITING_FOR_REVIEW to IN_REVIEW is silent, and so is the transition out of it in some cases, approvals with automatic release have been known to land before the email does.

The version's state is available from the API at any time, which is why anything watching the release for you can report the change immediately.

AppSubmit polls that state and posts a timeline entry on every transition, including the silent one into review, so the release page shows where you are without a manual refresh. The console shows the same value if you would rather check it yourself.

One last thing worth internalising: In Review is not a failure state and it is not a countdown. The only actions available to you during it are withdrawing, answering a question, and not breaking your own backend. Everything else is waiting.