PatchShort answer: The App Store cannot restore a previous binary to users who already updated; your options are a new expedited submission, a phased-release pause (which only stops further automatic updates), a kill switch or feature flag, or an OTA layer. With Patch, rolling back a patch recalls it from every device on the next check — no new build and no review.
Can you roll back to the previous App Store version?
No. App Store Connect has no control that restores an earlier binary to a device that has already installed a newer one. You can remove a version from sale, which stops new downloads, and you can submit a build that undoes the change — but the copy on a user's phone stays until that user installs something else. This is the structural difference between shipping a binary and shipping a patch, and it is why the rest of this page treats "rollback" as several different things wearing one word. The urgent-response menu, ordered by speed, is in the iOS hotfix playbook.
What does pausing a phased release do?
Pausing a phased release stops the automatic distribution schedule from advancing; it does not take the build back from anyone. Apple describes phased release as: "Selecting this option will release your app's update gradually over 7 days. A random sample of users with automatic updates on eligible devices will receive the update, without any notification of their participation in the phased release." The published schedule reaches 1%, 2%, 5%, 10%, 20%, 50% and 100% of users on days one through seven. Apple also notes: "During phased release, you may pause the release for up to 30 days, with no limit on the number of pauses" — and, crucially, that "apps and app updates in phased release can be manually downloaded from the App Store by anyone at any time".
— Apple, “Release a version update in phases”, retrieved 22 August 2026.
What does "rollback" mean for each option?
The word covers six mechanisms that revert different things for different populations. Only the last one reaches a device that already has the bad code and takes it away. Times below are qualitative on purpose: the segments that dominate them — Apple's review queue and your users' launch habits — are not yours to schedule.
| Option | What reverts | Who is affected | Time to effect | Needs review? |
|---|---|---|---|---|
| New App Store submission | Nothing reverts; you ship a newer build that undoes the change | Only users who install the newer build | Build, submit, review, then the installation tail | Yes |
| Expedited review request | Same as above, with the review segment shortened | Only users who install the newer build | Shorter, at Apple's discretion, and not guaranteed | Yes |
| Pause a phased release | Nothing reverts; automatic distribution stops advancing | Users who have not yet received it automatically | Immediate, but manual downloads continue | No |
| Feature flag / kill switch | Only the paths you wrapped in a flag before shipping | Every device that fetches the flag | Next flag fetch | No |
| Remote config | Only values the shipped code already reads | Every device that fetches config | Next config fetch | No |
| OTA patch rollback (Patch) | The whole patch: the previous module re-activates, or the device reverts to the signed binary | Every device on the channel, including ones already running the bad patch | Each device's next update check | No |
Read the third column first. A new submission and an expedited submission reach only the users who install the newer build, which is why neither is a recall. A phased-release pause governs automatic distribution and nothing else. Flags and remote config reach every device quickly but revert only what the shipped code was written to let them revert. The OTA row is the one that takes code off a device that already has it.
How does OTA rollback work in Patch?
One command rolls back the active release on a channel, from the CLI or from the Rollouts page in the console.
patchcli rollback --channel productionThe previous module re-activates and propagates to devices on their next update check. A device already running the rolled-back release, with no active replacement to take its place, is told to revert on that check: the SDK deactivates the patch locally and clears it, and the app runs the code compiled into the signed binary. That recall is the property the App Store cannot offer. Rollback is channel-scoped, and --to <version> targets a specific version, rolling back everything newer first. --dry-run shows what would happen without calling the backend. See the docs on staged rollouts and rollback and the CLI reference.
How do staged rollouts limit the blast radius?
A staged rollout means fewer devices ever see the bad release, so rollback has less to undo. Every Patch release carries a rollout percentage; the backend buckets each device by hashing its stable device id together with the release into a value from 0 to 99 and serves the release when the bucket is below the percentage. Because bucketing is deterministic, raising the percentage only ever adds devices, and a device already receiving the release never flips out of it. Channels are the second containment axis: a build subscribes to production, staging, beta or any string you choose, and receives only releases pushed to that channel, so an internal stream can absorb a bad patch first. See the channels documentation.
patchcli release --rollout 10 --message "Checkout total fix"What should a rollback runbook look like?
Decide first, diagnose second. The steps below assume a patch is live and something is wrong.
Confirm the deployment you are looking at: which channel, which version, what the failure rate is.
patchcli status --channel productionRoll the channel back. Do this before root-causing; the investigation is easier without users in it.
patchcli rollback --channel productionConfirm the active version changed and watch adoption of the restored module.
patchcli status --channel productionReproduce and fix in Swift, then re-release to a narrow slice rather than to everyone.
patchcli release --rollout 10 --message "Corrected checkout total"Widen the existing release from the console or the API once the failure rate holds. Re-running
releasepublishes a second module and re-buckets every device.
What can't be rolled back over the air?
A bad native binary. If the defect is in code that ships inside the signed app — a crash on launch before the SDK runs, a broken migration in native storage, a wrong entitlement, a framework-level bug — no OTA layer reaches it, because the patch runs inside that binary and cannot rewrite it. In that situation you are back to the App Store options at the top of this page: pause the phased release to stop the spread, use whatever flags you shipped, and submit a fix with an expedited-review request. The honest framing is that an OTA layer widens the set of defects you can recall; it does not make binary releases risk-free. What Patch can and cannot reach is mapped in the docs on coverage.
Should you use feature flags instead?
Use both; they solve adjacent problems. A feature flag reverts a code path you had the foresight to wrap before shipping, which makes it the fastest possible revert for a planned risk and no help at all for the bug you did not anticipate. An OTA patch reverts code you did not plan for, including the flag-evaluation logic itself, at the cost of a build and an update check. Teams that run both put flags around new features and keep the OTA layer for corrections. The trade-off is worked through in feature flags versus OTA updates, and the device-side mechanics in how OTA updates work on iOS.
Frequently asked questions
Does Apple let you revert an app update?
No. App Store Connect can remove a version from sale and stop a phased release from advancing, but it cannot restore an earlier binary to a device that already installed the newer one. Apple's own note on phased release is that apps in phased release "can be manually downloaded from the App Store by anyone at any time".
How long does expedited review take?
It depends, and Apple publishes no figure for expedited requests. Apple states only that "On average, 90% of submissions are reviewed in less than 24 hours" for ordinary submissions, and that you "can request the review of your app to be expedited if you face extenuating circumstances, such as fixing a critical bug". Expedited requests are granted at Apple's discretion.
Can feature flags replace rollback?
No. A flag reverts only the paths you wrapped before the build shipped, so it cannot undo a bug in unflagged code, in the flag-evaluation logic, or anywhere the flag was not threaded. Flags are excellent pre-planned containment and a poor general-purpose undo; an OTA layer covers the code you did not predict.
Does an OTA rollback need App Store review?
No. Rolling back a patch changes which interpreted module the backend serves; the signed binary on the device is untouched, so nothing is resubmitted. Apple's Developer Program License Agreement §3.3.1(B) governs what that module may contain, not how often you change which module is active.