How Long Does Apple Take to Review an App?

Short answer

Most App Store submissions come back within 24 to 48 hours in our experience, and Apple’s own guidance is that reviews are usually quick when a reviewer can get straight into the app: the App Store Review Guidelines ask you to provide full access, an active demo account or a fully-featured demo mode, and working backend services. A first submission from a new developer account often takes longer, and anything that triggers a question, subscriptions, account deletion, sign-in requirements, medical or financial claims, can add days. Plan for a week between submitting and being live, and never schedule a launch on the assumption of a same-day approval.

What the review actually involves

Review is a human process supported by automated checks. A reviewer installs the build, uses it, compares what it does against the App Store Review Guidelines, and checks the metadata: screenshots, description, age rating, privacy details and the account you provided for testing.

Three things happen in parallel and each can stall the whole submission. The binary is scanned for private API use and technical problems. The listing is checked for accuracy, and a screenshot showing a feature the app does not have is a rejection. And the reviewer looks for the categories Apple treats as sensitive: payments outside the permitted mechanisms, health claims, user-generated content without moderation, sign-in that demands more than the app needs.

The reviewer’s practical constraint matters more than founders expect: they have limited time and no context about your product. Anything they cannot reach, verify or understand quickly becomes a question, and a question becomes days.

Stage	Typical duration	What decides it
Waiting for review	Minutes to a day	Queue and account history
In review	Under an hour to a day	Complexity, sensitive categories
Approval to live	Up to a few hours	Your release setting
Rejection to resubmission	Your turnaround	How quickly you fix and reply
Expedited review	Same day, when granted	A genuine urgent reason

What makes a review take longer

A new developer account with no history is the most common cause of a slow first review. Nothing is wrong; the account simply has no track record. Submit the first build well before you need it.

Sensitive categories are the second: anything involving money, health, dating, gambling, children, or user-generated content. These get closer attention by design, and the difference between a two-hour review and a five-day exchange is usually whether you preempted the obvious questions in the review notes.

Missing test access is the third and the most avoidable. If the app requires an account and you did not supply working credentials, or the credentials expired, or the flow needs a code sent to a phone the reviewer does not have, the review stops. Provide a permanent demo account, keep it working, and explain any unusual flow in the notes field.

Ambiguous metadata is the fourth. Screenshots that show unreleased features, descriptions that mention platforms other than iOS, or an age rating that does not match the content all generate questions, and the privacy details you declare are checked against what the app actually collects.

Holidays are the fifth. Apple publishes shutdown periods around the end of December, and the days before them carry a surge of submissions.

Reducing your own review time

Write the review notes as if the reviewer knows nothing about your product, because they do not. State what the app does in two sentences, provide working credentials, explain any feature that looks unusual, and name the guideline you think applies if you are near a boundary.

Get the obvious rejection triggers right before submitting. Account deletion must exist in the app if the app lets people create accounts, which the guidelines state directly: if your app supports account creation, you must also offer account deletion within the app. Subscriptions need clear terms, restore purchase and a working link to your privacy policy. Anything that gives access to digital content must use in-app purchase rather than an external payment link, with the narrow exceptions Apple defines. Sign in with Apple is required where you offer certain third-party sign-in options.

Test the exact build you are submitting on a real device, not the simulator, on a clean install. Crashes on launch are still one of the fastest routes to rejection, and they usually come from an assumption about existing state that a fresh install does not satisfy.

Submit early in your week. A build submitted on Friday evening that hits a question spends the weekend waiting.

Before you submit	Why it matters
Working demo account in the notes	Blocked access stops the review immediately
Account deletion in-app	Required for apps that create accounts
Screenshots match the shipped build	Mismatched claims trigger a rejection
Privacy details match real data flows	Inaccurate declarations are checked
Clean install tested on device	Launch crashes are a common rejection
In-app purchase for digital content	External payment links are restricted
Review notes explaining unusual flows	Removes the question before it is asked

What happens if you are rejected

A rejection is a message in App Store Connect naming a guideline and usually describing the problem. It is not a verdict on the app and it is not rare; most teams that ship regularly have been rejected.

Two paths follow. If it is a misunderstanding, reply in the Resolution Center with a clear explanation and, where useful, a screen recording showing the behaviour. If it is a real problem, fix it and upload a new build. Either way the submission returns to the queue, and the second review is often faster because the reviewer has context.

The one thing not to do is resubmit the same build with no change and no explanation. It wastes days and it makes the exchange adversarial.

For genuine emergencies, a critical bug affecting live users, a fix tied to a fixed external date, Apple offers an expedited review request. The guidelines ask developers to seek it only when they truly need it and warn that abuse can result in future requests being refused, so treat it as a resource you spend rather than a shortcut you take.

Reading the status in App Store Connect

The status field tells you where a submission is, and knowing what each state means prevents the most common mistake, which is refreshing the page and inventing explanations.

Waiting for Review means the build is queued and nobody has looked at it. Nothing you do speeds this up except having submitted earlier.

In Review means a human has it open. This is the state where an unreachable app or a missing credential turns into a message rather than an approval, and it is also the state where a review can finish in fifteen minutes.

Pending Developer Release means you were approved and chose manual release. This is a good place to be sitting the week before a launch.

Rejected means there is a message waiting in the Resolution Center. Read the guideline number it cites before writing a reply, since the number tells you whether this is a factual disagreement or a policy one, and those need different responses.

Metadata Rejected is the mild version, where the app itself is fine and the listing is not. It usually resolves in one exchange because the fix is in App Store Connect rather than in a new build, which is why keeping screenshots and descriptions honest is worth the small effort it costs.

Planning a launch around this

Treat approval as a variable, not a date. The pattern that works: submit the build a week or more before your intended launch, choose manual release rather than automatic release on approval, and hold the approved build until you are ready. That way approval timing stops being a risk and becomes a milestone you have already passed when marketing starts.

Use TestFlight before submission rather than as an afterthought, since TestFlight builds go through a lighter review for external testers and surface metadata problems early. And plan the first update before launch, because the fixes that follow your first real users are the ones that matter most and they will also need review time.

Where these expectations do not hold

These timings describe ordinary consumer and business apps. They do not describe every case. Apps in heavily regulated areas can enter longer conversations about documentation and licensing. Apps that use a new Apple technology in its first weeks sometimes hit uncertainty on both sides. And an account with a history of rejections or policy problems does not get the same experience as a clean one, which is a reason to take the first submission seriously rather than treating it as a test.

If you are approaching a submission and want someone to read the build against the guidelines before Apple does, book a free app idea call and we will tell you what we would fix first.