Managed publishing: approved release not live for testers

Managed publishing holds a release after Google approves it, so approval is not the same as being live. When it is turned on, changes sit in "Changes ready to publish" on the Publishing overview page until you publish them yourself. Testers cannot install a build that is held, and the opt-in link in a testing track does not become live just because the review passed. Turn managed publishing off, or go to Publishing overview and publish the change, then confirm the track shows the new version before you send testers back to the link.

What does managed publishing actually hold back?

Managed publishing is a switch that separates review from release. Google's documentation states that changes are published automatically as soon as they are reviewed and approved, unless managed publishing is turned on. With it on, approved changes stop at the Publishing overview page and wait for you to act. Most developers enable it to schedule a launch to a chosen hour, to batch several listing edits into one visible update, or to hold a build until a marketing date. On a closed-testing campaign it has a side effect that surprises people: the build can be fully approved and still be unavailable to every tester in the track.

The mechanism is worth understanding precisely, because the console does not warn you that testers are waiting on a manual click. When managed publishing is on, the Publishing overview page splits your pending work into three places. "Changes not yet sent for review" holds edits you have made but not submitted, and nothing leaves that section until you click Send for review. "Changes in review" shows what Google is currently processing. "Changes ready to publish" shows what has been approved and is waiting on you. If a release sits in the third section, it is approved, and it is also not live.

Google notes that processing can take a few hours or up to seven days, and longer in exceptional cases, and recommends leaving a buffer of at least a week between submitting and going live. That means a developer who submits a build, watches the status flip to approved, and then tells testers to install can be wrong on two counts at once: the review may still be running, and once it finishes the hold may keep the build from ever reaching the track.

Which tester changes are held back and which are not?

This is the part that decides most support tickets, and it is a genuine trap. Managed publishing holds back the configuration of a track, but not the membership of the list behind it. Google lists changes to how testers are configured, such as setting a new email list or Google group as the list of testers, as held back. It then lists changes to the membership of an email list or Google group used by a testing track as an exception that is not held back.

The practical consequence is that adding a person to an existing Google group takes effect without publishing anything, while swapping the track from one list to a different list waits for you. Two developers can perform what looks like the same action, add a tester, and get opposite results. If a new tester reports that they can see the test but a recent build is missing, suspect a held release. If they cannot see the test at all, the list or group they were added to is probably not the one the track is using.

Why does the opt-in link stay dead after approval?

An opt-in link resolves against the track it belongs to, not against a review status. If the track's current release is held, the link still opens, the tester can still accept the test, and Play can still show the test as joined, but there is no downloadable build behind it. The tester sees an install button that fails, or sees the older version that was live before the hold. This is why "the link does not work" is a misleading description for what is usually a publishing state problem.

Work through it in order rather than guessing. First open the Publishing overview page and read the three sections. If your release is in "Changes in review", nothing you do to the tester list matters yet. If it is in "Changes ready to publish", the build is approved and held, and you need to publish it. If the release is not listed at all, it was never submitted, and the likely cause is that you saved a release without starting the rollout, or that the update was previously rejected and subsequent changes are not sent for review automatically, which Google documents as a case where you must click Send for review yourself.

Then check the track itself. A closed testing track must have a published release before any tester can install anything from it, and the opt-in link belongs to that track. A common sequence is to create the track, add testers, share the link, and only afterwards notice that the release inside the track is still a draft. Before you blame the tester's account, confirm that the track lists a release with the version code you expect, and that its status is not draft.

Does a held release delay the 14-day requirement?

Google's stated requirement for personal developer accounts created after November 13, 2023 is at least 12 testers opted in to a closed test for 14 continuous days before the account can apply for production access. Only opted-in testers count, and an invitation does not make someone opted in. The requirement is about tester state, not about your release pipeline.

That distinction is where a held build becomes expensive. Testers opt in by accepting the test and installing the build from Google Play. If the build is held and cannot be installed, a tester can accept the invitation without ever becoming an opted-in tester in the sense the requirement uses, and the continuous period does not accumulate the way you expect. The safe reading is that a hold can delay the campaign rather than the other way round, so publish before you tell testers to install. This conclusion is our analysis of how the two documented mechanisms interact, not a separate Google statement, and it is the reason we recommend treating publishing state as part of campaign setup rather than as a launch-day detail.

The countermeasure is to check two numbers instead of one. Count the addresses you have invited, and separately count what Play Console reports as opted in, then reconcile the gap before you assume the campaign is running. A tester who accepted an invitation while the build was held will look invited on your list and may look joined in the track, yet contribute nothing to a period that requires installation. Reading the opted-in figure directly is the only reliable check, because it is the number the requirement is measured against.

How do you clear the hold and confirm testers can install?

There are two ways out. Turning managed publishing off is the blunt one: Google states it can be turned on or off at any time, including while a change is being reviewed and processed, and changes then publish automatically once approved. Publishing the pending change from the Publishing overview page is the precise one, and it is the better choice if you kept managed publishing on deliberately for a launch date.

To publish deliberately, open Publishing overview and confirm the "Changes in review" section is empty and every change you want is under "Changes ready to publish". Then publish from that page. The build becomes live on the track it belongs to. Verify it from the tester's side rather than the developer's view: open the opt-in link in a browser signed in as a tester account, and check that the version code shown matches the build you intended to ship. Developer accounts often see their own app differently, and an internal testing track available to the developer account proves nothing about the closed track.

If the change you are waiting on was a switch to a new tester list, remember that the list change is itself held. Adding members to the group that is already attached will not move things forward while the attachment change is waiting. Publish, then re-send the opt-in link, then have one tester confirm the install before you message the whole group.

Frequently Asked Questions

Does approval mean the build is live?

No. With managed publishing on, an approved change waits in "Changes ready to publish" on the Publishing overview page until you publish it. Approval and availability are separate states.

Can I use managed publishing for my first release?

No. Google states the app must already be available to use managed publishing, and it cannot be used when publishing an app for the first time. For a first launch, publish the app to a testing track first.

I added testers but they cannot install. Which cause comes first?

Check publishing state before tester state. If the track's release is held or still a draft, every tester will fail to install regardless of their account or their opt-in status.

Do I need to publish after adding someone to a Google group?

No, if the group is already the track's configured tester list. Google lists changes to the membership of an existing list or group as not held back. Switching the track to a different list is held back.

Can turning managed publishing off break a scheduled launch?

It removes the manual gate, so approved changes publish automatically. If you turned it on to hit a specific hour, publish from Publishing overview instead of turning the switch off.

Sources

Every mechanic described above comes from Google's own Play Console documentation, read directly rather than summarised from third-party guides. The primary reference for the hold behaviour, the three Publishing overview sections, the held-back and not-held-back lists, the inability to use managed publishing on a first release, and the review timing is the Play Console Help article on controlling when app changes are reviewed and published. The 12-tester and 14-continuous-day requirement for personal developer accounts created after November 13, 2023, together with the rule that only opted-in testers count, comes from the Play Console Help article on app testing requirements for new personal developer accounts. The mechanics of publishing a release and starting a rollout on a testing track are documented in the Play Console Help article on preparing and rolling out a release. Where this article draws a conclusion that Google does not state outright, namely how a held build interacts with the continuous opt-in period, it is labelled as our analysis rather than presented as policy, because the two mechanisms are documented separately and their interaction is something we infer from how each is defined. If Google changes either workflow, the source articles above are the authority and should be checked before acting on anything here.

• Control when app changes are reviewed and published
• App testing requirements for new personal developer accounts
• Prepare and roll out a release

If your release is approved, published, and testers still cannot see the app, the next article to read is what to check when testers see the app as not available, which covers the cases that sit outside publishing state. If the count in Play Console is lower than the number of people you invited, fewer testers than you invited explains which invitations never became opt-ins. For the wider requirements that apply before you can request production access, see publishing requirements for new developers, and for the clock itself, the 14-day closed testing period.