Ship a third party SDK upgrade through a staged rollout on Google Play and a phased release on the App Store, watch crash and error rates at each step, and halt if they move. Both limit exposure, but neither recalls users who already updated, so the fix is another release.
What each store offers
A Google Play staged rollout sends an update to a percentage of users that you choose and can raise over time. Users are chosen at random, and they are not notified that they are in a staged group. You can halt a rollout if you find a problem. According to Google's help page, users who already received the version stay on it.
An App Store phased release applies to automatic updates and follows a fixed seven day schedule, per Apple's documentation.
| Day | Share of users with automatic updates |
|---|---|
| 1 | 1% |
| 2 | 2% |
| 3 | 5% |
| 4 | 10% |
| 5 | 20% |
| 6 | 50% |
| 7 | 100% |
Apple notes that anyone can still download the update manually from the App Store at any time during a phased release. You can pause the release for up to 30 days in total, with no limit on the number of pauses.
Why SDK upgrades deserve this treatment
An SDK upgrade is a change you did not write. Its behaviour on real devices, networks and OS versions is hard to predict from a test lab. A new payment, analytics or login SDK may fail only for certain account types or regions. Limiting exposure turns an outage into a small incident.
A practical plan
- Decide the signals before you start. Crash free sessions, startup time, login success, checkout success and SDK specific error counts are common choices.
- Record the baseline for the current release.
- Start Google Play at a small percentage and compare against the baseline. Wait long enough for slow signals such as background crashes.
- Let the App Store phased schedule run, and check at each day that matters to you, particularly days one to three where only a small share is exposed.
- If a signal moves, halt on Play and pause on the App Store. Then decide whether to fix forward or revert in a new build.
- Complete the rollout only after the metrics hold.
Remember the limits. A halt stops new users from receiving the update. It does not change the app on devices that already have it. If the upgrade fixed a vulnerability, a halt also stops the fix from spreading, so weigh the two risks.
Combine with server side control
For problems that a store pause cannot reach, design the app so the new SDK path can be switched off from the server, and tie that to a remote setting. Our post on forced updates and minimum OS versions covers the harder step of making old versions stop working.
Where Safeguard fits
Safeguard's dependency scanning and SBOM output help you see which SDK versions are in each release, so you can match a crash spike to a specific build. A free scan is at gold.safeguard.sh/scan.
Quick check
Does halting a staged rollout remove the update from phones?
No. Users who already received the version remain on it. You need a new release to change their app.
Can people on the App Store skip the phased schedule?
Yes. Anyone can download the update manually at any time, so some users will be ahead of the percentage.
Sources
- Google Play Console Help, Release app updates with staged rollouts: https://support.google.com/googleplay/android-developer/answer/6346149
- Apple, Release a version update in phases: https://developer.apple.com/help/app-store-connect/update-your-app/release-a-version-update-in-phases/
Last reviewed: 19 October 2026.
