Not in the way you can roll back a server. Once a user has the new build, the store will not revert it. You can stop further spread with a halt or pause, then ship a fixed build and, if needed, switch the SDK off from the server.
What the stores let you do
Google's Play Console help says that when you halt a staged rollout, no additional users receive the version. Users who already received it remain on it. Halting is also reversible, since you can resume, and a resumed rollout affects the same set of users.
Apple's documentation says you can pause a phased release for up to 30 days in total, with no limit on the number of pauses. It also notes that anyone can still download the update manually during the phased release, and that if you remove the app from sale, phased release stops for that version and cannot be used for it again.
Neither store describes a way to push users back to an older build. The recovery is a new version with a higher number.
Recovery options, fastest first
| Option | Speed | Needs |
|---|---|---|
| Halt or pause rollout | Minutes | Release still in staged or phased mode |
| Server side switch for the SDK | Minutes | Remote setting built into the app before release |
| Backend change that tolerates the bad behaviour | Hours | Server team available |
| Fixed build, reverting the SDK or patching around it | Days, store review dependent | New build, new rollout |
| Forced update of old versions | After the fix ships | Minimum version check in the app |
What to prepare before you ship
- Keep the last good version buildable. Pin it in the lockfile history and keep the release branch for it.
- Use staged and phased release for every SDK change. See staged rollout or phased release for an SDK upgrade.
- Add a server controlled switch around the SDK. A wrapper with an enabled flag lets you bypass the SDK without a release. Our post on wrapping a mobile SDK behind your own interface explains the wrapper.
- Have a minimum version check. If the bad build must be retired, you need a way to ask those users to update. See forced updates and minimum OS versions.
- Write the decision rule in advance. For example, halt if crash free sessions drop beyond a stated margin. Deciding during the incident costs time.
The fix is not always a revert
Reverting the SDK may bring back a vulnerability the upgrade fixed. Compare the risks. Sometimes the right move is to keep the upgrade, patch your own integration code and ship quickly. Our post on how fast you can ship a mobile fix covers the timeline.
Try it yourself
Click through it at your own pace, or open it full screen.
See how a fix path is presented so you can compare options before choosing between revert and fix forward.
Where Safeguard fits
Safeguard's autonomous remediation can open fix pull requests for dependency problems. It is off by default and every category starts on Manual, so a person decides what merges. Dependency scanning and SBOM output show which build contains which SDK version. A free scan is at gold.safeguard.sh/scan.
Quick check
If I halt a staged rollout, do users get the old version back?
No. Those who already received the new version stay on it. Halting only stops further users from getting it.
How long can I pause an App Store phased release?
Up to 30 days in total, with no limit on the number of pauses, according to Apple's documentation.
Sources
- Google Play Console Help, 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.
