You cannot directly downgrade or roll back to a previous version in App Store Connect, because Apple requires each new version to have a higher version number and does not let you re-release an old build as-is. The real fix for a bad release is to submit a new, higher-numbered version that contains the previous working code, and request expedited review so it reaches users quickly. To limit damage in the meantime, pause the phased release to stop the bad update from spreading to more users, and remove the app from sale if necessary. iOS itself does not let users downgrade an app they have already installed.
Short answer
There is no rollback button in App Store Connect, because version numbers must always increase and you cannot re-publish an old build unchanged. Per Apple's phased release guidance, you can pause a phased release to stop a bad update reaching more users, which is your fastest damage-control step. The actual fix is to ship a new, higher-numbered version containing the previous working code and request an expedited review so it goes out fast. You cannot force existing users onto an older build, since iOS does not support downgrading an installed app. Pause first, then push a corrected version.
Can you downgrade an app version in App Store Connect?
Not directly. Apple's model is forward-only: every new version must have a higher version number than the last, and you cannot select a previous build and make it the live version again. So the literal action of downgrading, reverting the store to an older version as it was, is not something App Store Connect offers.
This surprises people coming from systems with a one-click rollback, but it follows from how Apple versions apps. The practical consequence is that fixing a bad release is always a matter of moving forward with a new version, not backward to an old one. Once you accept that, the real options become clear, and they are effective even though none of them is labeled downgrade. What you are really doing is re-releasing your last good version and containing the bad one, which achieves the same outcome by different means.
The real fix: ship a new version with the old code
The reliable way to get working code back to users is to submit a new version that contains the previous, good code, with a version number higher than the bad release. In effect you re-release your last working build under a new number, which passes Apple's forward-only rule while giving users the behavior of the old version. This is the closest thing to a genuine rollback that the platform actually allows.
Prepare this build the same way you would any release, from the known-good source of the previous version, and make sure the version and build numbers are higher than the release you are replacing. Because it is a normal submission, it goes through review, which is why the next step, getting that review to happen quickly, matters when you are trying to undo a bad release fast.
Use expedited review to get it out fast
Because the corrected version must be reviewed, an expedited review is the alternative that turns a slow rollback into a fast one. When a live version is actively harming users, that is exactly the kind of time-sensitive, critical situation Apple's expedited review is meant for, so you submit the new version and request an expedite explaining that it fixes a critical problem in the current release.
Make the request specific. State that the live version has a serious bug affecting current users and that this submission reverts to working code, since a concrete description of user impact is what justifies an expedite. Keep in mind that an expedited review is faster, not automatic: the build still must pass review, so it should be your genuine previous working code, not a rushed patch that risks a rejection and further delay.
Pause the phased release to limit damage
While the fix is in review, stop the bad version from spreading. If you released the update using phased release for automatic updates, it rolls out to users over several days, and you can pause that rollout in App Store Connect, which stops it reaching additional users. Pausing does not remove the update from those who already have it, but it caps how many people are affected.
If the problem is severe, you can also remove the app from sale temporarily, which pulls it from the store entirely until you replace it. Neither action downgrades anyone who already updated, because iOS does not roll back an installed app, but both reduce the blast radius while your corrected version works through review. Pausing the phased release is usually the first, least disruptive move. It is reversible too, so you can resume the rollout later if it turns out the problem was smaller than you feared, without having pulled the whole app.
Options compared
Each option does a specific job, and knowing which is which prevents wasted effort. The table below compares them.
| Goal | Method | Note |
|---|---|---|
| Get working code back to users | New higher-numbered version with old code, expedited | Version must increase |
| Stop a bad update spreading | Pause the phased release | Existing installs keep it |
| Pull the app entirely for now | Remove from sale | Does not downgrade installs |
| Force users onto an older build | Not possible | iOS has no downgrade |
Read the table as a sequence rather than a menu. Pause the phased release to stop the spread, ship a higher-numbered version with the old code to fix it, and use an expedite to make that fast, while understanding that forcing a true downgrade on users is simply not available.
Rollback checklist
Acting in the right order limits the damage and gets the fix out fastest. The checklist below puts the steps in sequence.
| Check | Action | Done? |
|---|---|---|
| Pause rollout | Pause the phased release to cap the spread | [ ] |
| Prepare fix | Build a higher-numbered version from the good code | [ ] |
| Submit and expedite | Submit and request expedited review with the reason | [ ] |
| Consider removal | Remove from sale if the issue is severe | [ ] |
| Verify | Confirm the corrected version reaches users | [ ] |
The order matters because pausing is instant while a new version takes review time, so you pause first to stop new users being affected, then push the corrected build. Treat remove-from-sale as a stronger option for a serious problem, and always verify that the fix actually reached users once it is approved.
Prevent the bad build
The best rollback is the one you never need, since every step above costs time and affects users. Many bad releases trace to issues that a check before submission would have caught, and security and privacy problems are a common category, from a broken change that exposes data to a secret accidentally shipped in the build.
A scanner like PTKD.com analyzes your app build and reports findings ordered by severity and mapped to OWASP MASVS, so you catch issues like unjustified permissions, cleartext traffic, or embedded secrets before you ship. To be clear about the boundary: PTKD does not roll back a version, pause a phased release, or request an expedite. It helps you avoid shipping the kind of flawed build that forces a rollback in the first place.
What to take away
- You cannot directly downgrade a version in App Store Connect, because version numbers must always increase and old builds cannot be re-published unchanged.
- The real fix is to ship a new, higher-numbered version containing the previous working code, and request an expedited review to get it out fast.
- Expedited review is the alternative to a rollback: it makes the corrected version fast, but the build still has to pass review.
- Pause the phased release, and remove from sale if needed, to limit how many users the bad version reaches while the fix is in review.
- iOS cannot force users to an older build, so prevent the problem by scanning with PTKD.com before you ship.
