iOS app rollback: why you can't, and what to do instead

There is no iOS app rollback button on the App Store. Once a user has updated, Apple gives you no way to move their device back to an older version. To recover from a bad release, pause the phased release if one is running, turn off the broken feature from your server if you can, and ship a new version that fixes the problem or restores the old code.

You can lower the cost of a bad release before it happens, and most of that work has to be done ahead of time.

The steps below follow Apple's documentation. We did not test them on a live release, and App Store Connect labels can change.

What you can do in the first hour

The order depends on how bad the bug is.

1. Stop further spread. If the version is in phased release, pause it. If it's approved but not yet released, don't release it.
2. Turn off the bad path. Use a feature flag or a server-side setting if the broken code sits behind one.
3. Decide on the fix. Choose between a small fix and restoring the previous code.
4. Submit and request an expedited review. For a critical bug, ask Apple to expedite once the build is submitted.
5. Tell support. Give them the affected version numbers and what users can do meanwhile.

Pausing helps less than it sounds. Apple says versions in phased release can be manually downloaded by anyone at any time, so a pause holds automatic updates and nothing else.

The closest thing to an iOS app rollback

The closest thing to a rollback is shipping the old code as a new version. If 5.3.0 is broken and 5.2.4 was fine, build 5.2.4's commit with a new, higher version such as 5.3.1. Users get what looks like an update, and the code is the older behavior.

Two things can break this plan:

• Data migrations. If 5.3.0 changed a local database, the older code may not be able to read it. Test the path from 5.3.0 to your new build on a real device with real data before you submit.
• Server changes. If your backend already moved on, the older code may fail against it. Keep your API able to serve both versions.

To see what you would be taking out, compare the two release tags on GitHub.

Can you remove the bad version from the store?

Partly, and it rarely helps a current user. Apple lets you make a version unavailable for download to address legal or usability issues in a previous version. For a version in Ready for Distribution with such an issue, Apple says to submit an update, and if you can't, to remove the app from the App Store.

Removing the app from sale is a heavy step with side effects. Apple's phased release page says it stops the phased release for that version, and that reinstating the app makes the version available to all users immediately. It also doesn't touch installed copies. Keep this option for legal problems or a version that is doing real harm.

What users can do

A user generally can't choose an older version from the App Store. Their realistic choices are to wait for your fix, or to turn off automatic updates if they haven't updated yet. For a serious problem, tell them clearly what's affected, what still works, and when you expect a fix. Avoid suggesting that they delete and reinstall unless you know it helps, because deleting can remove local data.

How Android compares

Android has an option that iOS lacks, though it has the same basic limit. Halting a Google Play staged rollout stops new users from getting the update but doesn't take it back from people who have it. Google also lets you halt a fully rolled-out release on any track except internal testing. The previous fully rolled-out version then takes its place for new and eligible users. Google notes that this helps less once most users have already updated, and that you can't halt the first release on a track. To move people who have the bad version, ship a new release with a higher version code.

	App Store	Google Play
Slow the release	Phased release, fixed 7 days	Staged rollout, percentages you set
Stop the release	Pause	Halt, including after a full rollout
Undo for existing users	Not available	Not available
Fix path	New version, optional expedited review	New release with a higher version code

Prepare before the next release

Your options on the bad day are set by decisions you make beforehand.

Put risky changes behind a flag. A flag that you can switch off on the server reaches users who already updated, with no review.

Add a way to require an update. A minimum supported version, checked on launch, lets you move people off a dangerous version. It has to ship in the app before you need it.

Use phased release on anything risky, and name who checks the numbers each day. A bug found on day 2 reaches far fewer automatic updates than one found on day 7. Our post-deployment checklist suggests what to watch.

Keep a release record. On a bad day you will need the last good version, its commit, and its build number quickly. A hypothetical example: a team finds a crash in 5.3.0 at 09:00. If it takes an hour to work out which commit was 5.2.4 and whether the build still signs, that hour comes straight out of the response.

Specita keeps versions, source changes, and reported deliveries together per product, so the last good version and what changed since are in one place. With Sentry connected, crash data attaches to the matching release. Start with the App Store Connect guide.

Apple guidance checked on November 4, 2026.