Most Google Play updates go live the moment Google's review finishes. Managed publishing removes that assumption: it lets an approved change sit in a holding area until you press Publish changes, so the release ships on your schedule instead of the reviewer's. For a launch event, an ad campaign, a store listing refresh, or a portfolio of apps that all have to change on the same morning, it is the most useful switch on the Publishing overview page.
This guide walks the 2026 workflow end to end: what managed publishing holds back and what it does not, the permissions it needs, how to turn it on, the separate queue that decides what is even sent for review, the review windows you have to plan around, and the two cases where it does not apply at all.
One page, two decisions
Publishing in Play Console now separates two questions that used to be fused together. Both live on the Publishing overview page, and both can run at the same time.
- When does a change go to Google for review? Governed by the Changes not yet sent for review section. Every change that needs review is added there, and nothing moves to review until you click Send for review.
- When does an approved change go live? Governed by managed publishing. Once a change is reviewed and approved it lands in Changes ready to publish, and it stays there until you publish it.
What managed publishing holds back
Managed publishing holds back the vast majority of app changes. Google's documented examples:
- Full and staged rollouts of your releases, with the exceptions listed below.
- Launching and updating pre-registration.
- Store listing changes, including custom store listings and changes made to a live store listing experiment.
- App content changes — the material Google reviews your app with, such as the content rating questionnaire or your app's target audience.
- Changes to your app category.
- Managed Play settings.
- How testers are configured for a track — for example, setting a new email list or Google group as the tester list for that track.
- Country targeting changes that affect production and testing tracks, including every time a track is synced or unsynced with production, and changes to synced tracks that follow from a production country change.
What it does not hold back
A short list of changes bypasses the hold and publishes as usual. Google describes these as exceptions, "including but not limited to":
- Increasing an existing staged rollout to 100%.
- Updating your app's Release notes.
- Changes to device exclusion rules.
- Changes to the membership of an email list or Google group used by a testing track.
- Unpublishing your app.
- Changes to your app's In-app products page, and price changes.
- Stopping store listing experiments.
That second list is the reason a "held" release is never fully frozen: a price edit or a full rollout can still go out while the rest of your batch waits.
Prerequisites and permissions
Two rules come before the workflow. Your app must already be available — managed publishing cannot be used when publishing an app for the first time. And turning it on or off requires at least one of these permissions: Release to production, exclude devices, and use Play App Signing; Release apps to testing tracks; Manage testing tracks and edit tester lists; Manage store presence; or Admin (all permissions) — note that this last permission also grants every other permission, so it hands the user Admin access.
If you intend to use managed publishing for a product launch, Google's own recommendation is to publish the app to a closed testing track first.
Step 1 — Turn managed publishing on
- Open Play Console and go to the Publishing overview page.
- In the Managed publishing status section, go to Turn on managed publishing.
- Click Save.
- Confirm the state: a green check mark and the message "Managed publishing is turned on" stays in that section until you turn it off.
From that point on, make and submit changes as normal. They will not be published until they have been reviewed and approved and published from the managed publishing side of the page.
Step 2 — Decide what is even sent for review
The Changes not yet sent for review section is a queue you control. Each change gets a row with a high-level description and a link back to the change itself, and it waits there until you click Send for review.
This is where managed publishing gets genuinely useful for multi-change work:
- Save for later. If some changes are ready and others are not, click Save for later on the ones you are not ready to review. Saved changes can be viewed and undone back into the Publishing overview list — and once you send other changes for review, saved changes return to the overview automatically.
- Pull a change back. If a change has not yet been published, or is already sitting in Changes ready to publish, you can move it back into Changes not yet sent for review. That is the documented way to revert an unwanted change and keep it from going live before you want it to.
- Know the caveat. Removing a change from review, or from ready to publish, does not guarantee it escapes review — and Google warns that this can affect your publishing plans. Treat the pull-back as a control, not as a cancellation.
Step 3 — Track the review, then publish
- Select Publishing overview in the left menu and read the Changes in review table: Item changed names the item and the Play Console area (for example "Main store listing" or "App content"), and the Description column summarises the change. The arrow at the right of each row opens the relevant Console page.
- Wait until the Changes in review section is empty and every change you want has populated Changes ready to publish. While anything is still in review, Review and publish stays disabled — which is useful, because it stops you from publishing half a batch.
- Click Publish changes and confirm. Your update is live on Google Play within a few minutes.
The review clock you have to plan around
Processing can take a few hours or up to seven days, and longer in exceptional cases, because it depends on the review time your app is subject to. Google's guidance to its own developers is blunt: plan a buffer of at least a week between submitting and going live.
One queue rule catches teams out. The review turnaround is counted from the last change submitted to the app. Submit something new while other changes are still in review and your app can be pushed to the back of the review queue, and Review and publish stays disabled until the whole review finishes. In practice: batch your changes, send them once, then leave the queue alone.
That behaviour is also the argument for using managed publishing on accounts that are subject to extended review times — new developer accounts, for instance. It converts an unpredictable approval date into a publish button you control.
If your last update was rejected
Changes are not always sent for review automatically. Google's example: if an app update was rejected and you then made changes to resolve the issue, those changes are not sent for review by themselves — you have to open Publishing overview and click Send for review. After a rejection, always check the queue instead of assuming the workflow did it for you.
Turning it off
Managed publishing can be turned on or off at any time, including while a change is being reviewed and processed. Turning it off removes the hold, so anything already approved starts flowing out on its own from that moment. Treat the switch as a publish action and flip it only when you mean it.
Internal test tracks are outside managed publishing
Internal testing is not covered by managed publishing. In most cases, uploading an app bundle to an internal test track makes the change immediately available. Internal track updates are not subject to review, though they may be subject to retroactive review after going live. Two documented caveats:
- If your app's first release rollout is on an internal test track, that submission must be reviewed before it can be published. This does not apply to internal test apps that are not fully configured.
- If your previous submission was rejected, the next submission must be reviewed before it can be published — so an internal track upload will not become available until the review completes.
Checklist before you rely on managed publishing
- Is the app already published? Managed publishing cannot be used for a first release.
- Do you hold one of the five permissions above — and does everyone who will press Publish know the switch is live?
- Have you separated the changes you want reviewed now from the ones you clicked Save for later?
- Is anything in the batch on the exception list — a 100% rollout, a price change, release notes — that will publish regardless?
- Have you planned a buffer of at least a week between sending changes for review and the moment they must be live?
- Are you relying on an internal test track for something time-critical? Remember it ignores managed publishing entirely — except after a rejected submission.
The one-line model: managed publishing splits a Play release into two switches — Send for review decides what Google looks at, Publish changes decides when users see it. Approved changes and staged rollouts wait for you; price changes, release notes, tester-list edits, device exclusion rules and 100% rollouts do not. Reviews run from a few hours to seven days and the clock restarts from your last submission, so batch, send once, and publish on your own schedule.