TL;DR. There is no “revert to previous version” button in App Store Connect. Version numbers only go forward, and you cannot make an old build the live listing again. The closest thing, Last-Compatible Version Settings under Pricing and Availability, only controls which older builds users on old iOS versions can still install — it does not roll back what new users or already-updated users see. If a bad update ships, your real levers are pausing an in-progress phased release and submitting a corrected version, optionally with an expedited review request.

A bad update goes out, the crash reports start, and the instinct is to look for a rollback button. App Store Connect doesn’t have one. Knowing that before it happens saves you from burning ten minutes hunting through Pricing and Availability while users are already affected.

Can you roll back to a previous version on the App Store?

No. Apple’s own App Store Connect Help is explicit: if a live version has a legal or usability issue, “you must submit an app update” — there’s no mechanism to re-publish an older build as the current listing. Version numbers must always increase; you cannot select a prior build and make it live again.

This means the fix for a bad update is always a new, higher-numbered version, not a step backward. That new version does inherit your existing metadata (keywords, subtitle, description) as a starting point when you create it, so you’re not rebuilding your listing from scratch — only the build itself has to move forward.

What does the Last-Compatible Version setting actually do?

It is not a rollback. Last-Compatible Version Settings, found at the bottom of the Pricing and Availability page, controls which older approved builds remain installable for users on iOS versions too old to run your current release — it does not change what current-iOS users or already-updated users see.

Concretely: go to Pricing and Availability → Last-Compatible Version Settings → select a version, and you can deselect specific old builds so they’re no longer offered at all, or leave one available so a user still on an old iOS gets that older compatible build instead of being unable to install your app. Only versions that were actually submitted to the App Store show up in that list. The required role is Account Holder, Admin, or App Manager — Marketing does not have access to this page, the same restriction as the keyword field and subtitle (see our App Store Connect roles guide).

Two things this setting does not do: it doesn’t force an update or downgrade on a device that already has your current version installed, and it doesn’t affect what new users on a current iOS get — they always receive whatever your latest live version is.

What to actually do when a bad update ships

  1. If you shipped with a phased release still running, pause it first. Phased release rolls out to 1% of users on day one and climbs on a fixed 7-day schedule; pausing stops the percentage from climbing further while you prepare a fix. It does not undo the update for users who already got it. Full mechanics — the percentage schedule and the 30-day cumulative pause cap — are in our phased release guide.
  2. Prepare the corrected build as a new version. Increment the version number, fix the issue, and resubmit. Your keyword field, subtitle, and description carry over automatically — you’re not starting the listing over, only the binary.
  3. Request an expedited review if the bug is critical. Apple’s App Review page allows requesting expedited review for extenuating circumstances such as a critical bug fix, submitted with steps to reproduce the issue on the current live version. It’s not guaranteed — Apple approves or declines it — but for a crash-on-launch bug it’s the fastest path back to a normal review queue position. Note this only speeds up review; it doesn’t change when the fix goes live once approved, which still depends on your release option (automatic, manual, or scheduled).
  4. If it’s severe enough that neither option is fast enough, remove the app from sale. This stops new downloads entirely until you’re ready to resubmit — a last resort, not a first move, since it also stops legitimate new installs.

None of this touches your keyword field, subtitle, or ranking — a bad build and a bad listing are two different problems with two different fixes, and conflating them wastes the time you don’t have during an incident.