There is no rollback on the App Store, and on Google Play there is one.

Can you roll back a released version on the App Store?

No, and Apple says so in the one place people go looking. The App Store Connect Help page titled Make a version unavailable for download opens by framing itself as a tool for legal or usability issues in a previous app version. Then it draws the line: if the status of the version is Ready for Distribution and the version has a legal or usability issue, you must submit an app update, and clearly describe the previous version's issue in your submission. If you are unable to submit an update, you must remove the app from the App Store. Those are the two routes. There is no third one.

The control that page describes is still worth knowing, because it is often mistaken for a rollback. You open Apps, select the app, click Pricing and Availability in the sidebar, and scroll to the bottom, to Last-Compatible Version Settings. A dialog lets you deselect versions that should not be available on the App Store, and you click Done and then Save. Only versions submitted to the App Store appear in that list. You need to be the Account Holder, an Admin or an App Manager. Reversing it is the same dialog: once the issue is resolved, you choose which versions to make available again.

What it governs is which of your submitted versions the App Store is willing to hand out, which matters for devices too old to run the newest one. It is not a time machine for the current release and it does not touch a phone that already updated.

The blunt instrument is Remove App From Sale, at the bottom of the same Pricing and Availability page, behind a confirmation dialog. Apple says the app will be removed from the App Store in all countries or regions within 24 hours. Read the next two sentences carefully before you reach for it: users who previously downloaded the app will continue to receive app updates, and the app can be redownloaded from a customer's purchase history as long as the necessary contract remains active. So it closes the front door. It does not fix the broken build for anyone who already walked through it, and it costs you every new install while it is in force.

App Store Connect Help, make a version unavailable for download, read 16 October 2026

What does halting a rollout do on Google Play?

Two different things, and the difference is the whole answer. Google documents halting in two places, one for a rollout that is still part way through and one for a release that has already reached everybody.

The staged version is the modest one. On the Production page, or the Open testing or Closed testing page, you open the Releases tab and select Manage rollout followed by Halt rollout. Google states the effect plainly: no additional users will receive the app version in your existing staged rollout, and users who already received it will remain on that version. If the bundle turns out to be fine you resume from the same menu, set a percentage and confirm. Worth knowing: a staged rollout percentage never increases on its own, so a halt is stopping something you were driving by hand.

The second one is the closest thing to a real rollback that either store offers. For a release that has fully rolled out, Google says the halt rollout feature minimizes disruption for users by preventing new and existing users from installing or updating to the affected version, that the halted version will no longer be served to users, and that a previously live version will automatically take its place and become available to new and eligible users. The path is the same: Releases tab, Manage rollout, Halt rollout. A halted release can be resumed to any percentage of users, which is how you reintroduce it gradually once it is fixed.

Google publishes the limits too, and they are the part to read before you rely on this. It works on any track except internal test tracks. You cannot halt the first release on a track, so a brand new app has nothing to fall back to. If the previous release has a policy violation it cannot be used in place of the halted one. And Google warns that for a release that has been live a long time, or that many people have already taken, halting might not be the most effective solution, which is a polite way of saying it only helps the people who have not updated yet.

Play Console Help, halting a fully rolled out release, read 16 October 2026

What do you do in the first hour after a bad release?

Work out how far the release actually got, before you touch anything. The right control is a different control at each stage, and two of them are one way doors. A version still sitting in Pending Developer Release has not reached a single customer, and the fix is to leave it there. A version you released manually offers Cancel This Release on the version page, and Apple notes it can take up to 24 hours to appear on the App Store either way. A rollout you are driving by percentage can simply be stopped. Only a fully live release needs the hard choices.

If the bad build is in a phased release, pause it, but understand what you bought. Apple gives you 30 pause days in total, with no limit on the number of pauses, and a resume picks up on the day it left off. The catch is in the same help page: apps and app updates in phased release can be manually downloaded from the App Store by anyone at any time. The phased schedule only governs automatic updates. Anyone who opens your product page and taps Update still gets the broken version while you are paused.

There is one trap in combining the two Apple controls, and Apple spells it out. If the app is removed from sale while a version is in phased release, the phased release stops and will not be available for that version again. When the app is reinstated, that version becomes available to all users immediately, regardless of the percentage it had reached. Pull the app to stop a phased rollout and you have swapped a slow leak for a flood on the day you come back. Apple does say you can restart a controlled rollout, by making the version unavailable for download and submitting a new version update with phased release enabled, which is the fix forward route again.

One more thing to check in the first hour: what the bug touches. A cosmetic bug can wait for a normal review turnaround. A broken purchase flow is money and support tickets, and how bad it is depends on where the money lives, which is a reason to decide which payment layer to use long before an emergency rather than during one.

Why will neither store let you re-upload the old binary?

Because version numbers only count upwards, by design. Play Console Help says Android requires app version codes to increase with every release to prevent accidental downgrades, and describes the version code as a 32 bit integer that consistently increases with each new release. The ceiling Google publishes is 2,100,000,000, which is also a reason not to invent a numbering scheme that climbs fast. The App Store applies the same logic to version strings and build numbers.

That is why the Play halt is a genuinely different mechanism from an upload. Google is not letting you publish old bytes with an old number. It is choosing to stop serving one version and serve a previously live one instead, inside its own distribution. You can put earlier bytes in a new release, with Add from library in Play Console, but that release still needs a version code above whatever is live. A rollback by upload is always a new release that happens to contain old code.

So the rollback you actually control is the one in your repository. Reverting the commit and building again is the only move that works identically on both stores, and it is the only one that leaves you with a version number higher than the broken release. Keeping the last good commit findable is worth more in this hour than any console setting. None of these controls costs money, which is the cheerful note: halting, pausing, pulling and resubmitting are all free, and they are not part of what it costs to publish an app. What a bad release costs you is review time and reputation.

The last piece is telling people. Neither store notifies users that they were part of a rollout, and neither tells them a version was halted. Google says users are not notified when they receive a staged rollout version. If the bug lost someone data or money, the only channel that reaches them is yours.