Releasing App Updates Safely: Phased Release and Staged Rollouts

Why release gradually

Testing comes first, and our guide to testing a mobile app before release covers TestFlight and the Play testing tracks. But real users have devices and data no test plan fully covers. A gradual release means a bug that gets through reaches a small group first, and you can stop before it reaches everyone.

Gradual releases apply to updates only. Google says staged rollouts "can only be used for app updates, not when publishing an app for the first time", and Apple offers phased release when you submit a version update. For a first launch, see our guide to publishing an app to the App Store and Google Play.

App Store: phased release over 7 days

Apple's help page on releasing a version update in phases explains that the option releases an update "gradually over 7 days" to "a random sample of users with automatic updates on eligible devices". Users are not told they are part of a phased release. The schedule is fixed:

• Day 1: 1% of users, day 2: 2%, day 3: 5%, day 4: 10%
• Day 5: 20%, day 6: 50%, day 7: 100%

Two details matter when you plan around it. First, the percentages apply to automatic updates only: Apple notes that an update in phased release "can be manually downloaded from the App Store by anyone at any time". Second, you choose phased release in the version's "Phased Release for Automatic Updates" section in App Store Connect, before or during review, and this needs the Account Holder, Admin or App Manager role.

You can pause a phased release for a total of 30 days, with no limit on the number of pauses; when you resume, it picks up on the day where it stopped. You can also click "Release to All Users" at any time once the version is Ready for Distribution, for example once you are confident in it. Apple's release options also let you release manually after approval, or automatically but no earlier than a date you set.

Google Play: staged rollouts

Google's help page on staged rollouts describes a more hands-on model. You choose the percentage of users who get the update when you roll it out, and you raise it yourself: "your app's staged rollout percentage won't increase automatically." Staged rollouts work on the production track and on the open and closed testing tracks.

• Who gets it: new and existing users are chosen at random for each release. If you halt and then resume, the same set of users is affected.
• Countries: for a production release you can limit the staged rollout to specific countries or regions. Once the rollout has started, you cannot remove countries.
• Timing: the update becomes available to the chosen percentage, but Google notes it "may take time for the full group to receive the update".
• One at a time: Google's page on preparing and rolling out a release says you cannot create a new release while you have outstanding releases; roll staged releases out to 100% or discard them first.

Google also advises updating the store listing only after the release reaches 100% if the update needs listing changes, and closely monitoring crash reports and user feedback during the rollout. Users in a staged rollout can leave public reviews; see our guide to app ratings and reviews.

When something goes wrong

On Google Play you can halt a staged rollout from the Releases tab with Manage rollout, then Halt rollout, or from the Play Console app. Google explains that "no additional users will receive the app version", while "users who already received the app version in your staged rollout version will remain on that version". If the build turns out to be fine, you can resume. If it has a real problem, Google's advice is to "create and roll out a new release with a fixed app bundle".

On the App Store, the equivalent is pausing the phased release while you investigate. Pausing slows automatic updates, but anyone can still download the version manually, so a serious bug still needs a fixed version submitted for review.

In both cases the decision depends on seeing problems early. Set up crash reporting before you release, not after; our guide to crash reporting and app stability explains how. Play Console's release details also keep a rollout history of when a release was halted, resumed or widened.

Prompting users to update on Android

A release only helps users who install it. The Android Developers guide to in-app updates describes a Google Play Core libraries feature "that prompts active users to update your app", on devices running Android 5.0 (API level 21) or higher. It offers two flows:

• Flexible updates download in the background while the user keeps using the app, suited to updates that are not critical to its core function.
• Immediate updates are full-screen flows that "require the user to update and restart the app in order to continue using it", meant for updates critical to the core functionality.

The implementation guide adds two signals for choosing between them. Staleness tells the app how many days have passed since the update became available on the Play Store, so you might wait a few days before a flexible prompt and a few more before requiring an immediate update. Priority is a value from 0 to 5 that you set per release through the Google Play Developer API; it "can only be set when rolling out a new release and cannot be changed later". Google's example strategy: no prompt for minor UI changes, a flexible update for performance improvements, an immediate update for a critical security fix.

Old versions and a minimum supported version

Because users who already have a version keep it, and users who turn off automatic updates may stay behind for a long time, several versions of your app will be in use at once. That has two consequences for the backend the app talks to:

• Removing or renaming something in the API that an older version relies on can break it for everyone still on that version.
• Decide when an old version can no longer be supported, for example after a security fix, and how those users will be told.

On Android, an immediate in-app update is the store-supported way to require an update. A common design that works on both platforms is for the app to ask your backend for the minimum version it supports at start-up, and to show a clear message with a link to the store listing when the installed version is older. Build this check into the first version you release, so it is there when you need it. Our guide to mobile app backend options covers where such settings can live.

Release notes

Both stores show users what changed. In App Store Connect, the "What's New in this Version" field is limited to 4000 characters, is required for every version after the first, can be localized, and Apple recommends giving the specifics of the changes, improvements or fixes. On Google Play, you add localized release notes under "What's new in this release?", and Google says not to use them "for promotional purposes or to solicit user actions". The Play release name, by contrast, is only visible in Play Console, so use it for your own build number.

A simple release routine

• Test the build on the testing tracks and TestFlight first.
• Confirm crash reporting and analytics work in the release build.
• Make sure backend changes still work with the versions already in use.
• Release with phased release on iOS and a low staged rollout percentage on Android.
• Watch crashes and reviews daily; raise the Play percentage step by step, or pause or halt if something is wrong.
• Update the store listing after the rollout is complete, if it needs changes.

Releases are part of ongoing care; our guide to mobile app maintenance covers yearly OS releases, SDK deadlines and store rules.

Frequently asked questions

Can we roll back an app update?

Not in the way you can roll back a website. On Google Play, halting a staged rollout stops new users getting the version, but users who already received it remain on it; Google's advice for a real problem is to roll out a new release with a fixed app bundle. On the App Store you can pause a phased release, then submit a fixed version.

Should every update use a gradual release?

It is a sensible default for updates that change how the app works. Apple lets you release to all users at any time during a phased release, and on Google Play you choose the percentage, so an urgent fix can still go out to everyone quickly.

Can we force users to update?

On Android, the in-app updates API offers an immediate update flow that requires the user to update and restart the app to keep using it. On both platforms, the app can also check a minimum supported version from your backend and ask users on older versions to update from the store.

Do users know they are in a phased release or staged rollout?

No. Apple says users receive the update without any notification of their participation, and Google says users won't be notified if they receive a version in a staged rollout.

Apps need ongoing care after launch: regular updates, crash monitoring and an up-to-date backend. See our mobile app development service and all our services, or email [email protected].