How Long Does App Store Review Take? Statuses and Expedites
Last updated
You have finished the build, filled in the metadata and pressed Submit. Now you wait, and the question every small team asks is how long. Apple does say how quickly it works, and the answer is better than its reputation. This guide covers what Apple says as of 26 March 2026, explains the statuses you will see, lists what slows a review down, and covers expedited review for when you can't wait.
Shipping on Android too? The Google Play version of this guide is How Long Does Google Play Review Take? Statuses and Planning.
The short version
- As of 26 March 2026, Apple's App Review page says that most submissions are reviewed within 48 hours.
- Complex apps, new kinds of issues and repeated rejections for the same guideline take longer.
- Incomplete submissions are the most common cause of delay you can control.
- You can request an expedited review for a critical bug fix or an event-related launch. Use it sparingly.
- After approval, allow up to 24 hours for the app to appear on every storefront you selected.
What Apple says about timing
Apple's App Review page says, as of 26 March 2026, that most submissions are reviewed within 48 hours. It adds that you are notified of status changes by email, that you can check status in App Store Connect or in the App Store Connect app for iPhone and iPad, and that incomplete submissions may take longer or not pass.
The After You Submit section of the App Review Guidelines fills in the rest. A complex app, or one that presents new issues, may need more scrutiny. An app that is repeatedly rejected for the same guideline, or that tries to manipulate review, takes longer. And once a version is released, it can take up to 24 hours to appear on all the storefronts you chose.
Treat that as a typical figure, not a promise. Plan your launch with a few days of slack, especially for a new app, a big update or anything in a regulated category.
The statuses you will see
Apple's reference page on app and submission statuses lists every status. These are the ones a typical update passes through, as of 26 March 2026:
| Status | What it means |
|---|---|
| Ready for Review | Metadata is complete and you have indicated you will submit, but you haven't yet. |
| Waiting for Review | Apple has your submission and hasn't started. You can edit some information and remove the build from review, but you can't upload or edit screenshots or previews. |
| In Review | App Review is looking at it. You can still remove the build from review. |
| Pending Developer Release | Accepted. You chose to release it yourself, so it waits for you. |
| Processing for Distribution | Being prepared for the store. Apple says it will be ready within 24 hours. |
| Ready for Distribution | Accepted and ready. Your agreements must be in effect for it to go out. |
| Rejected or Metadata Rejected | App Review didn't accept the build or the metadata. Read the message, fix it and reply or resubmit. |
| Developer Rejected | You removed it from review yourself. |
App Store Connect also shows submission-level statuses, including Unresolved Issues when one or more items in a submission were rejected. Apple's overview of submitting for review notes that each platform can have one app version under review at a time, plus one more submission of items such as in-app events or custom product pages. It also says submissions may not be reviewed in the order you submit them.
What slows a review down, and what you control
The App Review page puts it plainly: if your app needs special settings, account details or instructions, put them in the App Review Information section, or review may be delayed. In practice, most avoidable delays come from the same few gaps:
- No working demo account. If the app needs a login, the reviewer needs one that works on the day.
- A backend that is down or behind a feature flag. Guideline 2.1 asks you to keep services live during review.
- Unexplained features. Anything non-obvious, from hardware requirements to in-app purchases, belongs in the review notes.
- Placeholder content. Lorem ipsum or "coming soon" screens are a guideline 2.1 rejection, which costs a full round trip.
Our guide to the App Review Guidelines covers the rules behind most rejections.
Expedited review
Apple lets you ask for a faster review when you face extenuating circumstances. As of 26 March 2026, the App Review page names two:
- A critical bug fix. Include the steps to reproduce the bug in the current version of your app.
- An event-related app. Apple recommends scheduling the release in advance. If the app is still in review and the event is close, you can ask, and your request should name the event, its date and your app's connection to it.
You make the request through Apple's expedited review form. The guidelines ask you to respect other developers by asking for it when you truly need it, and warn that Apple may reject future requests if it finds the system being abused. A popular feature you want out by Friday is not a critical bug.
Bug fix submissions
There is a second, lesser-known relief valve. If you submit a bug fix update and App Review finds other issues, you can choose to resolve them in your next submission, as long as there are no legal or safety concerns. You accept by replying to the offer message in App Store Connect. That keeps a crash fix from waiting on an unrelated metadata question.
Planning a release around review
- Submit early and release by hand. Choose to release the version yourself, and the accepted build waits in Pending Developer Release until launch day. Review time stops being on your critical path.
- Or pick a date. App Store Connect can release the version as soon as it is approved, or no earlier than a date you set.
- Use TestFlight while you wait. External testing needs its own beta review. Our TestFlight beta testing guide covers how that works.
- Leave room for one rejection. If a launch date matters, assume one round trip.
How FeedbackKit fits in
The gap between "we built it" and "it is live" is where request status gets muddled. A user who asked for a feature sees nothing change for days, while your team considers it done.
FeedbackKit gives every request one of six statuses on every plan: Pending, Approved, In Progress, TestFlight, Completed and Rejected. A simple rule keeps them honest through review. Keep a request at In Progress, or at TestFlight while beta testers have it, until the version is approved and released. Move it to Completed when people can actually download it from the App Store. Until then, "Completed" promises something your users can't get.
Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:
From Approved to TestFlight
The admin app runs on Mac, iPad and iPhone, so you can move a request on the day App Review approves the build, wherever you are. Sorting by the total MRR of the users behind each request helps you decide what goes into the next submission. It won't get you an expedite, and it shouldn't. SDK setup is in the Swift docs, with Kotlin and Flutter for your other platforms.
If you want one place to track what is waiting on review, start free.