How Long Does Google Play Review Take? Statuses and Planning

You have uploaded the bundle, filled in App content and sent your changes for review. Now you wait, and the question is how long. Google gives a range rather than a promise, and it says plainly that some accounts and apps wait longer. This guide covers what Google says as of 22 September 2026, what stretches a review, how to read the statuses in Play Console, and how managed publishing lets you take review off your launch day.

The short version

• Google says review can take a few hours or up to seven days, and longer in exceptional cases.
• Certain developer accounts, including new ones, and certain apps get extended reviews.
• Sending more changes while an update is in review can push it to the back of the queue.
• Managed publishing holds approved changes until you publish them, for apps that are already available. It doesn't hold everything.
• After a rejection, fix every issue, then send for review again by hand, or appeal.

What Google says about timing

As of 22 September 2026, Google's help page Publish your app says that for certain developer accounts it will take more time to review your app thoroughly, to help protect users, and that this may mean review times of up to seven days or longer in exceptional cases. For updates it says the same about certain apps: with standard publishing, updates are processed and published as soon as possible, but some apps are subject to extended reviews.

Google's page on managed publishing gives the range for all changes: processing can take a few hours or up to seven days, or longer in exceptional cases, depending on the review time your app is subject to. It recommends a buffer of at least a week between submitting and going live.

So plan on a week, and treat anything faster as a bonus.

What makes a review longer

Google names some causes directly. Others follow from how Play Console works.

• A new developer account. The managed publishing page lists apps submitted by new developer accounts among those subject to extended review times.
• Certain apps. Google says certain apps get extended reviews and doesn't list which. If your app requests high-risk or sensitive permissions, such as SMS or Call Log, you may also need an approved Permissions Declaration Form, which Google evaluates during the release.
• Changes sent while another review runs. Google says the review turnaround is counted from the last change you submitted, so a change sent while others are in review may push your app to the back of the queue.
• A previous rejection. After a rejected submission, the next one must be reviewed before it can be published, even on the internal testing track, which is otherwise exempt.
• Missing sign-in details. If any part of the app needs a login, the App content page asks you to provide everything a reviewer needs to get in. Give them credentials that work on the day.

Two other things delay a launch without being review at all. Since 31 August 2026, new apps and updates must target Android 16 (API level 36) to be submitted, as our target API level guide explains. And personal accounts created after 13 November 2023 need a closed test with 12 testers for 14 days before production, covered in our 12-tester guide.

How to check the status

Play Console shows your app's publishing status under its name and package name when you select the app. As of 22 September 2026, Google's Publish your app page describes three kinds: the app status (who can get the app), the update status (where your latest set of changes stands) and the item status (each part of an update, such as a release or a store listing change). These are the update statuses you will see most:

The Publishing overview page is the place to watch. It lists your changes in three groups: Changes not yet sent for review, Changes in review, and, with managed publishing on, Changes ready to publish. You can save some changes for later and send the rest, and move changes that are in review or approved back out if you don't want them published.

Managed publishing: what it holds and what it doesn't

Without managed publishing, Google publishes your changes as soon as it approves them. With it on, approved changes wait until you click Publish changes, and Google says they then go live within a few minutes. You can turn it on or off at any time, even while a change is in review.

As of 22 September 2026, Google's managed publishing page says it holds back the vast majority of changes, including:

• full and staged rollouts of your releases;
• launching and updating pre-registration;
• store listing changes, including custom store listings and live store listing experiments;
• App content changes and changes to your app category;
• Managed Play settings, and changes to how testers are configured for a track.

Google lists exceptions that go out without waiting, including but not limited to:

• increasing an existing staged rollout to 100%;
• updating the release notes;
• changes to device exclusion rules;
• changes to the members of an email list or Google Group used by a testing track;
• unpublishing your app;
• changes to your In-app products page, and price changes;
• stopping store listing experiments.

Two limits matter for planning. Managed publishing needs an app that is already available, so you can't use it when publishing an app for the initial time. And internal test tracks aren't covered by it: an internal release is usually available straight away and isn't reviewed beforehand, though Google says it may be reviewed after it goes live.

If a price change and a new feature have to land together, remember that the price change doesn't wait.

Planning a launch around review

• Give a new app a closed test. Google strongly recommends publishing to a closed testing track before you use managed publishing for a product launch. Once the app is available on that track, you can switch managed publishing on, send the production release for review, and publish it on launch day. Our testing tracks guide covers the tracks.
• Leave a week. That is Google's own recommended buffer. Leave more for a new account.
• Send everything in one go. Finish the store listing, App content and release before you click Send for review, so a late change doesn't restart the clock.
• Check sign-in details and permissions before you submit, not after a rejection.
• Use staged rollouts for risky updates. See staged rollouts on Google Play.

After a rejection

As of 22 September 2026, Google's page on its enforcement process says that when it takes action, it emails you the details and instructions on how to appeal. For a rejection, it says:

• the rejected app or update is not made available on Google Play;
• if an update was rejected, the version you published before stays available;
• a rejection doesn't affect the standing of your developer account;
• you shouldn't resubmit until you have fixed all the policy violations.

Read the email carefully, and look beyond the issue it names: Google says its removal and administrative notices may not list every violation in your app. Then fix and resubmit, or appeal if you believe the decision was wrong. A resubmission after a rejection isn't sent for review on its own: go to the Publishing overview page and click Send for review. If the problem was sign-in details, Google's App content help says you can update them and resubmit without contacting the policy support team.

Don't treat rejections as free. Google lists repeated app rejections or removals among the causes of a suspension, which counts as a strike against your account. Our guide to the Google Play Developer Program Policies covers the rules behind most rejections. If you also ship on iOS, see App Store review time.

How FeedbackKit fits in

The days between "we built it" and "it's live" are where request status gets muddled. A user who asked for a feature sees nothing change, 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. FeedbackKit's beta status is called TestFlight, after Apple's service, and Android users see that same label. Many teams use it to mean "in testing", whichever store's beta it is. A simple rule keeps the statuses honest through review: keep a request at In Progress, or at TestFlight while your closed testers have the build, until Google approves the release and you publish it. Move it to Completed when people can download it from Google Play.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

Moving a request to Completed is also the moment to tell people. FeedbackKit emails the person who submitted it when the new status is in your project's list, on every plan; see closing the loop. The board itself runs in your app through the Kotlin SDK, or the Flutter and React Native SDKs. To keep track of what is waiting on review, start free.