Google Play Staged Rollouts

A note-taking app is shipping a sync fix. You do not want every install to take it tonight. On Play you choose the percentage. Ten percent means ten until you say otherwise. Nothing in the console advances you to twenty while you sleep. That is the whole contrast with Apple’s seven-day ladder, where day 3 becomes 5% without a meeting. Here the meeting is the feature.

Google’s article is Release app updates with staged rollouts . Apple’s fixed calendar is App Store phased release. Reviews that show up before 100% are answered in how to reply to Google Play reviews. If the first publish is what you are trying to stage, you are in the wrong feature. The first production release is not a staged rollout. A new personal account’s closed test is a different gate, and Google’s article distinguishes that closed track from internal testing.

You pick the percent, and it stays there

Staged rollouts work on production and on test tracks, and only for an update. The first time you publish, this control is not available. New and existing users are eligible, chosen at random for each new release rollout. It can take time for the full group at your percent to actually receive the update. They are not notified that their version arrived via a staged rollout. Your monitoring has to assume silence.

To raise the percent you go to the release and choose Manage rollout, then Update rollout, enter the new percent, and confirm. There is no schedule hiding behind that button. A note-taking app left at 10% on Friday is at 10% on Monday. If you start a new staged release before the previous one reached 100%, the new release uses the same group of users as the previous one, depending on the percentage. You do not get a fresh random slice just because the version code changed.

How this differs from Apple’s ladder

Play waits for you to raise the percent and keeps the same users across halt and resume. Apple moves through a fixed seven-day table unless you pause.

Countries are a one-way add

You can start a production staged rollout in a limited set of countries. By default, country availability matches the production track’s locations. Country availability options show up when you are updating a production release, not as a free-form switch on every test track. Once the rollout has started, you cannot remove a country. Add only places where you are willing to leave the note app’s sync fix running if Monday’s crash log is ugly.

The path Google prints: open the Production page, or Open testing or Closed testing if that is the track, select Releases, Edit the release, skip unchanged Prepare steps by reviewing the release, set the rollout percentage, and under Country availability choose specific countries or regions. Then start the rollout to production. If you cannot see Production, you lack permission to manage production releases. Do not discover that at the moment you wanted to halt.

Reviews arrive before 100%

Google says to watch crash reports and user feedback during the rollout, and that users who received the staged version can leave public reviews. A 10% sync fix on the note app can collect 1-star notes the same day. Those notes are the sample. Read them before you confirm a higher percent. You can reply in public while the percent is still low. One reply per review, and they get notified. Do not tell them the store is “only testing” in a way that pretends their install is unofficial. They have the build.

If the crash is real, halt. Additional users stop receiving that version. The phones that already updated keep it, and they can still review. Ship a new bundle with the fix rather than hoping a resume of the bad bundle gets kinder. Resuming the same bundle without a fix puts the same user set back in line for a version you already do not trust.

Change the listing after 100% when it must match

Play lets you update listing text and graphics separately from a bundle, which is handy, and dangerous during a partial rollout. If the update requires a store listing change, Google recommends making that change after the release is at 100%. The new editor’s screenshot should not be the storefront while 90% of users still have the old editor. A reply on a single review can name the version code early. The listing is what everyone sees.

Listing visitors and acquisitions, for people who did not already have the app, will move if you change screenshots mid-rollout for a reason only the new bundle justifies. Leave the default listing aligned with the build most new visitors can install. How those counts work is in Google Play store listing conversion. Custom listings are not a reason to advertise a half-rolled editor as if it were the product.

A 10% plan for the note app

Start the sync fix at 10%, in the countries you already support, unless you have a reason to add a smaller country set you will not be allowed to remove. Watch crashes and the public reviews for a day you would actually read, not for an hour. If the editor opens and notes sync, update the rollout to a higher percent on purpose. If they do not, halt, keep those users in mind because they still have the bundle, and roll a fixed bundle. Move screenshots of the new editor when the rollout is at 100%, if the listing has to show that editor.