Why Does Apple App Review Take So Long?

If you develop iOS apps, you probably know the feeling.

You finish the release. You upload the build. You submit it to App Review.

And then you wait.

The App Store Connect status says “Waiting for Review.”

A few hours pass.

Then a day.

Then two days.

You refresh App Store Connect again.

Still waiting.

The frustrating part is that Apple says most submissions are reviewed very quickly. Apple currently states that 90% of submissions are reviewed in less than 24 hours, and almost all are reviewed within 48 hours. Apple also says it reviews approximately 175,000 new apps and app updates every week.

So why can an individual app sometimes take several days—or even longer?

The answer is more complicated than simply saying “Apple is slow.”

The 24-hour number is an average, not a promise

This is probably the most important thing to understand.

When Apple says 90% of submissions are reviewed in less than 24 hours, it doesn’t mean that your submission will be reviewed within 24 hours.

It means that most submissions fall into that window.

There is still a long tail.

Imagine 100 submissions:

• 90 might be reviewed within 24 hours.
• A number might take 24–48 hours.
• A smaller group might take several days.
• A very small number might take substantially longer.

That last group is what developers experience as “Apple Review is taking forever.”

Apple explicitly acknowledges that some submissions require additional time. It also says review time can depend on the complexity and novelty of the issues involved, including cases that require internal escalation.

In other words, the average is useful for understanding the system at scale, but it isn’t a reliable SLA for your particular release.

“Waiting for Review” and “In Review” are very different

One of the easiest ways to misunderstand App Review is to treat every waiting state as the same.

They aren’t.

Waiting for Review generally means your submission is in Apple’s queue and has not yet been picked up for the actual review.

In Review means the review process has started.

That distinction matters.

If your app has been sitting at “Waiting for Review” for several days, the delay may have little to do with the contents of your application. It may simply be waiting for processing and assignment.

Recent Apple Developer Forum discussions show developers reporting submissions remaining in “Waiting for Review” for several days, and some reports in 2026 describe delays lasting considerably longer.

That doesn’t necessarily mean Apple found something wrong with the app.

Sometimes the app simply hasn’t reached the reviewer yet.

Apple is reviewing an enormous number of submissions

The scale of the App Store is easy to underestimate.

According to Apple’s March 2026 DMA compliance report, Apple reviews approximately 175,000 new apps and app updates every week.

That’s roughly:

25,000 submissions per day.

Of course, the real distribution isn’t perfectly uniform, and Apple uses automated systems and other processes before and alongside human review. But the scale explains why a queue exists in the first place.

The App Review system isn’t processing a few hundred applications a day.

It’s processing an enormous global stream of new applications and updates across multiple platforms, categories, regions, and regulatory environments.

Not every app requires the same amount of review

Another important factor is complexity.

A simple utility app with no account system, no payments, no unusual permissions, and no complicated backend may be relatively straightforward to evaluate.

A financial application is different.

A social network is different.

A dating application is different.

An app involving user-generated content is different.

An application with subscriptions, purchases, authentication, location access, sensitive data, or complex business logic can require more scrutiny.

Apple’s own documentation says that review time can depend on the complexity and novelty of the issues raised, and that some cases may require escalation internally.

This is one reason there isn’t a simple formula such as:

“Small update = 2 hours, big update = 8 hours.”

The review isn’t purely based on the number of lines of code or the size of the binary.

It’s about what Apple needs to verify.

App completeness can create delays

Apple specifically highlights Guideline 2.1: App Completeness as one of the most common sources of unresolved issues.

Apple says that more than 40% of unresolved issues are related to this guideline.

This includes things such as:

• crashes
• incomplete functionality
• placeholder content
• missing information
• broken links
• incomplete metadata
• features that reviewers cannot properly test

This is especially important for applications that require an account.

Imagine the reviewer installs your application and immediately encounters a login screen.

If you haven’t provided working test credentials or instructions, the reviewer may not be able to access the functionality you’re asking them to evaluate.

From the developer’s perspective, the application is finished.

From the reviewer’s perspective, it may be impossible to test.

Apple explicitly asks developers to provide specific settings, account information, and review instructions when they are necessary. Apple warns that missing this information can delay the review process or result in rejection.

The reviewer has to understand your app, not just install it

This is another reason review can take longer than expected.

A reviewer doesn’t necessarily know your product.

You do.

Your team has spent months thinking about the architecture, business model, edge cases, and user flows.

The reviewer may have only your binary, metadata, screenshots, and review notes.

So if an important feature isn’t obvious, the reviewer has to investigate.

For example:

“The premium feature becomes available after completing onboarding.”

That may be obvious to your team.

But if the reviewer doesn’t know how to reach it, they have to discover the flow themselves—or ask for clarification.

Good App Review notes effectively reduce the amount of detective work required.

Payments and business models can add complexity

Apps that sell digital goods, subscriptions, or premium functionality naturally attract additional attention because Apple’s business rules apply.

This doesn’t mean every subscription app will take longer.

But it does mean there are more rules that can potentially become relevant.

Apple’s App Review Guidelines cover business requirements alongside safety, performance, design, and legal requirements.

This is particularly important when your application has:

• subscriptions
• in-app purchases
• paywalls
• account-based premium features
• external payment flows
• marketplace functionality
• financial services
• user-generated content

The more complicated the business model, the more carefully you should prepare your review notes and test account.

New apps can be different from routine updates

Developers sometimes assume:

“It’s just a small update, so it should be reviewed immediately.”

Usually, a small update is indeed simpler.

But Apple doesn’t publish a guarantee that updates receive priority over new applications.

A first release can also require additional context because the reviewer is seeing the application for the first time.

And even an apparently tiny update can touch functionality that matters for review.

Changing a login flow, payment system, content moderation system, permissions, or subscription behavior can turn a “small code change” into a meaningful review change.

Sometimes the problem really is the queue

This is the uncomfortable answer.

Sometimes you’ve done everything correctly.

Your agreements are active.

Your metadata is complete.

Your test account works.

The app doesn’t crash.

The review notes are clear.

There are no obvious guideline issues.

And you’re still waiting.

Recent Apple Developer Forum posts from 2026 contain multiple reports of apps remaining in “Waiting for Review” for several days, including reports of week-long and longer delays.

There are also reports from developers describing unusually long review periods lasting weeks. These reports are anecdotal rather than an official Apple statement that there is a universal outage, but they demonstrate that Apple’s published average does not describe every individual submission.

So if you’re sitting at “Waiting for Review” for several days, don’t immediately assume your code is broken.

You may simply be on the wrong side of the distribution.

What about weekends, holidays, and release periods?

Developers frequently wonder whether weekends or holidays are responsible for longer review times.

Apple doesn’t publish a simple rule saying:

“Reviews take X% longer on weekends.”

So it’s better not to treat that as fact.

What we can say is that Apple acknowledges periods of higher-than-average submission volume can cause delays. Apple’s App Review FAQ specifically notes that there can be times during the year when submission volume is higher and review times are delayed.

That matters because release volume can be highly seasonal.

If thousands of developers are trying to ship around the same major event, holiday, platform release, or industry deadline, the queue can behave differently from an ordinary week.

Why doesn’t Apple simply add more reviewers?

This sounds like an easy solution.

More submissions?

Hire more reviewers.

But App Review isn’t simply a mechanical checklist.

Apple says that apps are evaluated by App Review specialists and that reviewers receive standardized training on how to apply the guidelines. Apple also says applications are routed to reviewers with relevant experience and training for apps of the same nature.

That means increasing capacity isn’t necessarily as simple as adding arbitrary people to a queue.

Review quality matters.

Consistency matters.

Security matters.

Privacy matters.

And Apple’s goal is not merely to approve applications quickly. It is to evaluate whether they comply with the rules governing the App Store.

There is also an unavoidable trade-off

Apple is trying to optimize two competing goals:

Review applications quickly.

And:

Don’t compromise the safety and quality of the App Store.

Apple explicitly describes this trade-off in its 2026 compliance report, saying that App Review aims to reach decisions quickly while maintaining the safety and security of the App Store and its users.

From a developer’s perspective, the first goal is much more visible.

You see:

Waiting for Review…

Apple has to consider the second goal as well.

That’s why “just approve everything faster” isn’t really a viable solution.

So, how long should you actually expect?

The safest answer is:

Plan around the average, but don’t depend on it.

Apple currently says:

• 90% of submissions are reviewed in less than 24 hours.
• Almost all are reviewed within 48 hours.
• Some submissions require additional time.

For product planning, I would therefore avoid building a release process around:

“We can submit Friday morning and launch Friday afternoon.”

Instead, treat App Review as an external dependency.

If your launch matters, submit early enough that a multi-day delay doesn’t break your schedule.

What can developers actually do?

You can’t control Apple’s queue.

But you can reduce the chances of unnecessary delays.

1. Submit a genuinely production-ready build

Don’t use App Review as your final QA environment.

Test on real devices.

Test the critical user journeys.

Test login.

Test payments.

Test subscriptions.

Test deep links.

Test permissions.

Test network failures.

And especially test the exact build you submit.

Apple specifically recommends thoroughly testing applications and fixing bugs before submission.

2. Give the reviewer everything they need

If your application requires an account, provide a working test account.

If a feature requires special configuration, explain it.

If there is a non-obvious workflow, describe it.

Don’t make the reviewer guess.

3. Keep review notes short and useful

You don’t need to write an essay.

Tell the reviewer:

• how to log in
• where to find the important features
• how to reproduce special functionality
• what configuration is required
• anything unusual about the application

The goal is to remove friction.

4. Don’t repeatedly cancel and resubmit

When your app is stuck, the instinct can be:

“Maybe I’ll cancel it and submit again.”

That can make the situation worse rather than better.

Recent developer reports include cases where developers canceled a delayed submission and resubmitted it, only to end up waiting again.

Unless you have a specific reason to withdraw the submission, repeatedly resetting the process isn’t a reliable strategy.

5. Use expedited review only when you genuinely qualify

Apple provides an expedited review process for certain situations.

Examples include critical bug fixes and apps associated with time-sensitive events. Apple asks developers requesting expedited review to explain the circumstances and, for critical bug fixes, provide reproduction steps.

It shouldn’t be treated as a general:

“My launch is tomorrow, please review faster.”

mechanism.

6. Build review time into your release process

This is probably the most important lesson.

If your release process looks like this:

Code complete
    ↓
QA
    ↓
Submit to Apple
    ↓
Launch

you’re taking a significant risk.

A better process is:

Code complete
    ↓
QA
    ↓
Submit to Apple
    ↓
Wait for review
    ↓
Approval
    ↓
Launch

The difference is subtle but important.

Apple Review is a dependency, not a deterministic build step.

The real problem isn’t that Apple is always slow

The data tells a more nuanced story.

Apple says 90% of submissions are reviewed within 24 hours, and Apple processes roughly 175,000 submissions every week.

At the same time, recent 2026 developer reports show that some submissions can remain in “Waiting for Review” or “In Review” for days or substantially longer.

Both things can be true.

For most developers, App Review is relatively fast.

For a smaller number of developers, the experience can be painfully slow.

And when you’re responsible for the release of an important application, being in that small percentage is enough to make the entire process feel broken.

Final thoughts

Apple App Review is slow when you are waiting for it.

That’s the paradox.

Statistically, the process is fast for most submissions.

Operationally, however, a single unexpected delay can completely disrupt a product launch.

The biggest mistake isn’t necessarily submitting an app that takes a long time to review.

The bigger mistake is planning your business around the assumption that Apple will always review it within 24 hours.

Prepare your app thoroughly.

Give reviewers everything they need.

Avoid unnecessary resubmissions.

Use expedited review when you genuinely have an eligible urgent case.

And, most importantly, leave enough time between submission and your planned launch.

Because the App Store review queue doesn’t care that your marketing campaign starts tomorrow.

And that’s exactly why experienced iOS teams treat App Review as part of release planning—not as the final button they press five minutes before launch.