Why app review is taking so long?

A slow review does not automatically mean your app has a problem. Learn how to distinguish a queue delay from a blocked submission, what Apple and Google actually promise, and when to contact support.

You have uploaded the build, checked the screenshots, and planned your launch. Then nothing happens. App Store Connect still says Waiting for Review, or Play Console keeps your changes under review. Meanwhile, every day of uncertainty makes it harder to coordinate marketing, customer support, and a release announcement.

The frustrating part is that a delay has several possible explanations. Your submission might simply be waiting its turn. A reviewer might need information. Your build might not have reached review at all. Or review might already be finished, with publication waiting on you. This guide explains how to tell those situations apart. It focuses on Apple App Review, with a separate Google Play comparison. Sources were checked on 3 October 2026.

How long should app review take?

Apple says that, on average, 90% of submissions are reviewed in less than 24 hours. That is useful context, but it is not a guaranteed turnaround for your individual app. Some submissions fall outside that window, and the statistic does not give you a completion time for those exceptions. Apple also warns that incomplete submissions can delay review. [1]

Treat that number as a planning reference, not a launch commitment. A submission taking longer than a day is not, by itself, evidence of rejection or a broken account. Equally, an average should not persuade you to ignore an actionable message. The status and the reviewer correspondence matter more than comparisons with another developer’s fastest approval.

First, identify where the delay actually is

Read the precise status rather than translating every yellow indicator into “Apple is reviewing my app.” Waiting for Review means the submission is queued; In Review means review has started. Pending Developer Release means the app has been accepted but still needs your release action. Waiting for Export Compliance is a different process. An accepted item can also remain unpublished if another item in its submission was rejected. [2]

Check the app version and submission together, not just the uploaded build. A screenshot of the build list can tell a different story from the submission page. Write down the version, build number, submission time, and current status. That small record prevents you from troubleshooting an older build or confusing a TestFlight submission with an App Store release.

Reviewers need to experience the complete app

A reviewer cannot assess a feature they cannot reach. Apple’s submission checklist asks for full access, an active demo account or appropriate demo mode, necessary hardware or sample resources, and live backend services. It also asks developers to explain non-obvious features and purchases in the review notes. These requirements make access a sensible first place to investigate. [3]

Test the exact credentials you supplied, preferably on a clean device. Check whether an account needs email verification, a paid entitlement, an invitation, or a one-time password. Try the onboarding path without your development account. If a feature requires a particular region or a second user, explain how the reviewer can reproduce that setup. Do not assume they will infer your intended workflow.

A short, reproducible walkthrough is more useful than a sales pitch. For example: sign in with the supplied account, open Library, select the sample project, and tap Export. Include any expected limitation and explain why it exists. This does not buy priority; it reduces avoidable ambiguity when someone reaches your submission.

A rejection needs an answer, not more waiting

When Apple rejects an app, its message explains the issue and the relevant guideline. App Store Connect lets you reply and attach supporting material. Apple also states that a metadata rejection can be resolved and resubmitted using the same build. A fresh binary is therefore not always necessary. [4]

Respond to the specific objection. If the reviewer could not find a feature, provide the navigation steps. If their concern is a misleading screenshot, correct the screenshot. If you disagree, explain the behaviour and provide evidence rather than repeating that competing apps do it. Separate what you changed from what you are asking Apple to clarify.

Keep a simple issue log: the reviewer’s question, your response, the changed asset or build, and the next required action. That makes subsequent correspondence easier to follow. It also stops a team from independently submitting different explanations. Review communication is a debugging conversation, not a contest to send the longest reply.

Build processing and TestFlight are separate checkpoints

An uploaded build is not necessarily ready for submission. Apple’s build-status reference distinguishes processing, missing compliance information, and readiness to submit. It also distinguishes TestFlight’s Waiting for Review and In Beta Review states from availability for internal testers. External beta testing can require TestFlight App Review. [5]

If your beta is stuck, inspect its build status before looking for an App Store review queue problem. For Missing Compliance, Apple instructs developers to answer the encryption questions or supply the relevant documentation. Some builds can declare an applicable exemption through their configuration, but you should answer accurately rather than changing settings just to bypass the prompt. [6]

Approved does not always mean immediately available

Apple’s publishing workflow separates choosing a build, setting availability, submitting, resolving review issues, and distribution. It says that an approved app can take up to 24 hours to go live. You also choose whether release is manual, automatic, or phased. Check those settings before describing an approved version as “still in review.” [7]

For updates, a phased release gradually distributes the version to eligible users with automatic updates over seven days. That is a rollout choice, not seven extra days of review. If one customer still sees an older version, first confirm the release method and availability rather than assuming the reviewer has withheld approval. [8]

Google Play has a different review window

Do not apply Apple’s headline timing to Google Play. Google says reviews can take a few hours or up to seven days, and longer in exceptional cases. Its publishing overview also warns that submitting another change while changes are under review can push the app back in the review queue. Repeated small edits can therefore work against a predictable release. [9]

Play Console’s publishing overview distinguishes changes under review from changes ready to publish. With managed publishing enabled, approval and publication are separate decisions. Look at the queue of changes, not just whether the new listing is visible on a phone. Finish the intended release package before submitting it, and avoid unrelated edits while waiting unless something genuinely needs correcting.

A practical example: diagnose before resubmitting

Imagine a habit-tracking app submitted on Monday morning. On Tuesday evening, the founder starts rebuilding it because approval has not arrived. Before doing that, they check three things: whether the version is actually queued, whether review has sent a message, and whether the supplied account can complete onboarding. This is an illustrative scenario, not a measured AsoTheory customer case.

If the app is simply waiting and access works, a replacement build offers no demonstrated solution. If a reviewer reports a login failure, fixing access addresses a real obstacle. If the status is Pending Developer Release, the correct action is release, not resubmission. The same elapsed time can require three entirely different responses. That is why diagnosing the state comes before choosing a remedy.

When should you contact Apple?

For an unexplained, unusually long delay, use Apple’s review contact route with a concise timeline and submission identifiers. Describe the current state, any previous correspondence, and what you have already checked. There is no universal day-count threshold in the cited guidance that guarantees escalation. Avoid inventing one or promising that a support message will move your app forward.

Expedited review is a separate request. Apple gives examples such as a critical bug fix or a release tied to an event you are directly associated with. Explain the actual circumstance and impact; ordinary marketing impatience is not the same thing. An expedited request should not be presented as a guaranteed shortcut. [1]

Plan the launch around uncertainty

A useful internal release note has four fields: what is changing, what customers can currently access, who is watching review correspondence, and what triggers the announcement. Assign one person to own the submission. Agree on a check-in schedule instead of having everyone refresh the console all afternoon. Keep the evidence together, including reviewer messages and the exact version submitted. None of this shortens Apple’s queue, but it prevents uncertainty from turning into unnecessary rebuilds or conflicting decisions.

If your release adds a new subscription or changes onboarding, prepare support answers before approval arrives. Make sure your marketing links describe the version people can actually download. Avoid announcing that a feature is live just because its build has been accepted. For a first launch, have a fallback landing-page message ready. These are operational recommendations, not store requirements or promises about review speed: their value is that your team can still act sensibly when the timeline is outside its control.

Keep review preparation on a release checklist: working access, clear notes, tested purchase flows, accurate assets, monitored correspondence, and a deliberate publication setting. Leave room between submission and any fixed campaign date. If timing is essential, decide in advance what happens if approval arrives late: pause the announcement, keep the current version available, or communicate a revised window.

Finally, distinguish evidence from stories. Other developers’ long waits may be real, but they do not prove why your app is delayed. Neither the cited Apple nor Google guidance establishes a universal explanation such as AI-generated apps causing a backlog. The useful question is not “what rumour explains this?” It is “what state is my submission in, and is there an action I can actually take?”

Blog · Case studies · Free ASO tools · Products · Privacy and terms · AsoTheory