A hotfix is only fast if it can ship without a new binary.
Where the bug lives decides how fast you can fix it, and nothing else does. A bad value on your own server or behind a remote switch is live in minutes. A JavaScript bug can go out over the air in minutes too, but only if the build people already installed contains an update client. A native crash, a permission or an SDK version means a new binary and a review queue, and no amount of urgency changes that. So the first job is not shipping. It is reading the crash, which is what debugging crashes is for.
The second job is limiting how many more people see it. Both stores let you slow a release that is still going out. Neither store takes a version back from someone who already updated. Every control name, percentage and limit below comes from Apple's and Google's own documentation, read on 10 October 2026.
Start hereThe short version
Stop the rollout first. Then ship the fastest fix allowed.
Halting a Google Play rollout or pausing an App Store phased release takes about a minute and needs no build. Shipping the fix takes anywhere from minutes to a week. Doing those two things in the wrong order puts more people on the broken version while you wait on a queue, and that is the part of an incident you control for free.
What no store gives you is an undo. Anyone who already updated keeps what they have until something newer reaches them, so every real fix moves forward. That is also why the routes below are worth deciding in advance, as part of ordinary app maintenance rather than at two in the morning with a one star review arriving every minute.
What should you do in the first hour?
Work on exposure before you work on code. On Google Play that is Manage rollout then Halt rollout. On the App Store it is Pause Phased Release, if the version was submitted with phased release turned on. Both are a minute of clicking and neither needs a build. Then answer one question: does this fix require a new binary. That single answer separates a ten minute hotfix from a two day one, and everything else in this article follows from it.
The routes, fastest first. One, change it on your server or in remote config, because nothing in a store blocks that. Two, publish an over the air update, if the installed build can receive one and the fix is non native. Three, build a new binary and submit it. Apple's App Review page, read on 10 October 2026, says review typically covers at least 50 percent of submissions in less than 24 hours and 90 percent in less than 48 hours. Google Play Console Help says processing can take a few hours or up to seven days, and longer in exceptional cases. Four, ask Apple to go sooner. A critical bug in a live app is one of the circumstances Apple names, and the expedited review request is where that goes.
Two things not to do in that hour. Do not submit a build you have not run, because a failed review costs you the whole queue again and a second bad version costs you more than the first. And do not let the fix widen. A hotfix is one change that removes one symptom. Anything else goes in the next release, where it can be tested like normal work.
It helps to know your numbers before you choose. How many users are on the broken version, how fast they update, and whether the crash hits everyone or one device family. A bug that affects 2 percent of installs on a phased release day two is a different problem from one that breaks launch for everybody, and it deserves a different answer.
App Store Connect Help, release a version update in phases, read 10 October 2026
Pick one
What actually broke?
The route is decided by where the bug lives, not by how urgent it feels. Pick the closest one.
Nothing picked yet. If you cannot tell which of these it is, the first job is the crash report, not the release.
Can you stop an App Store release that is already going out?
Partly, and only if you turned phased release on when you submitted. Apple's phased release spreads an update over seven days on a fixed schedule: 1 percent of users on day one, then 2 percent, 5 percent, 10 percent, 20 percent, 50 percent, and everybody on day seven. It reaches a random sample of users who have automatic updates turned on, on eligible devices, and they are never told they are part of it.
The pause lives on the version page. In Apps, select the app, click the version marked Ready for Distribution in the sidebar, then in the Phased Release for Automatic Updates section select Pause Phased Release and click Save. Resuming uses the Use Phased Release option in the same place, and the schedule picks up on the day it stopped rather than starting again. You get 30 days of pause in total, with no limit on how many separate pauses that is: spend ten days and you have twenty left. Account Holder, Admin or App Manager can do it, and nobody else.
Now the part that catches people. Pausing does not hide the version. Apple's page states that apps and app updates in phased release can be manually downloaded from the App Store by anyone at any time. Phased release only governs automatic updates. Anyone who opens your product page and taps Update while you are paused gets the build you were trying to contain, which means a pause buys you time rather than safety.
There is no rollback in any of this. Apple documents no way to put the previous version back, and its own route to a controlled rollout again is to make the version unavailable for download and submit a new version update with phased release enabled. Removing the app from sale, including when a developer program membership lapses, stops phased release and that version can never use it again. When the app comes back it goes to all users immediately, whatever percentage it had reached. If you never enabled phased release in the first place, there is nothing to pause: the only control on that part of the page is Release to All Users, which does the opposite of what you want today.
App Store Connect Help, pause and resume a phased release, read 10 October 2026
How do you halt a Google Play rollout?
Open Play Console and go to the Production page, or to Open testing or Closed testing if the bad release is on a test track. Select the Releases tab, find the release, then choose Manage rollout and Halt rollout. You need permission to manage production releases, so if the menu is missing, that is why. Google is exact about what halting buys you: no additional users will receive the app version in your existing staged rollout, and users who already received it remain on that version.
The rest of the menu matters for what comes next. Manage rollout then Resume rollout restarts the same release in front of the same set of users, and Update rollout changes the percentage, which never moves on its own. The Play Console app can resume a halted rollout too, through Staged rollout then Resume rollout then Resume. Country availability is one way only: once a staged rollout has started you cannot remove countries from it, so narrowing a release after the fact is not an option.
Two limits decide whether this helps you at all. Staged rollouts exist only for app updates, not for publishing an app for the first time, so a broken first release has no rollout to halt. And if you pushed straight to 100 percent, there is no staged group left to stop. In both cases the answer is Google's own tip for a bad bundle: create and roll out a new release with a fixed app bundle, and keep the percentage low while you watch it.
One quiet advantage on Android is worth using. Users are not notified when they receive a version from a staged rollout, so a halted rollout does not announce itself either. Nobody goes hunting for the version you just stopped. On iOS the equivalent is not true, because the product page keeps offering the latest approved build to anyone who taps Update.
Play Console Help, release app updates with staged rollouts, read 10 October 2026
When does an over the air update beat a new build?
When the fix is JavaScript, styling or an image, and the build people already installed can receive one. Expo's EAS Update documentation, read on 10 October 2026, sets that scope plainly: it serves updates to projects that include the expo-updates library, and it updates an app's non native pieces over the air. One command publishes the bundle and assets, users get the new version on their next app launch, and by default the library checks for an update every time the app loads. Reverting is the easy direction: you republish a previous stable version on top of the problem one, much like another commit.
The list of things it cannot carry is short and firm. A change to native code or a native dependency. A change to app permissions such as camera or location. An Expo SDK version upgrade. Anything else that needs a new binary version. All of those go through a build and a store review, which is why the triage question at the top of this page is the one that matters.
Two honest limits before you count on this route. The update client has to be inside the binary people are running today, and you cannot add it retroactively to an app already on a phone, because it ships as part of a build. Platform rules also still apply: Expo says updates need to follow App Store and Play Store guidelines, which usually means changes to your app's behavior need to be reviewed. The pattern its own documentation describes for an emergency is to get the critical fix out as an update and then follow up with a new submission that has the fix built in. If none of this is set up yet, our notes on over the air updates cover what adding it costs you in practice.
If you cannot update over the air, the plain route is the one Google spells out for a bad app bundle: create and roll out a new release with a fixed bundle, and halt the old rollout while you do it. It is slower, it is the one everybody ends up using at some point, and it is also the route that gets you a version everyone can install rather than only the users whose build happened to support updates.
Play Console Help, halt a staged rollout and roll out a fixed app bundle, read 10 October 2026
The routes, and how fast each one really is
| Route | How fast | Goes through review | The catch |
|---|---|---|---|
| Server or remote config change | Minutes, on the next request | No | Only reaches what you did not compile into the app |
| Over the air update | Minutes to publish, next app launch per user | No | Needs an update client already inside the installed build |
| Halt or pause the rollout | Minutes, in the console | No | Caps new installs only, nobody is moved off the bad version |
| New build through review | Hours to days, both stores | Yes | Does nothing for users sitting on the broken version until they update |
| Expedited review request | Unknown, Apple publishes no turnaround | Yes | iOS only, and it is a request rather than a control |
Where this lands if a builder generated your app
The consoles are yours either way, and that is the part worth checking before you need it. App Store Review Guideline 4.2.6 says apps created from a commercialized template or app generation service are rejected unless the provider of the app's content submits them, so the Apple Developer account, the submit button and the pause control sit with you, not with the tool. The same is true of Halt rollout in Play Console.
Newly is an AI app builder: you describe an app in plain English and it writes a real React Native and Expo project you own, running it on cloud iPhone and Android simulators while it builds. It is $25 a month and there is no free plan. iOS builds go up to TestFlight through App Store Connect with your own Apple Developer account, and the Android side builds, signs and uploads to Google Play internal testing as well as producing a standalone release APK. It does not submit to the App Store for you, because Apple requires the owner of the content to do that.
What it does not add is an update client, which is why the over the air route is a decision you make rather than a feature you inherit. Two things make that decision cheap. The project is a normal Expo project, so adding expo-updates later is an ordinary dependency change. And two way GitHub sync means the code is in a repository you can open, patch and build from while the agent is not involved, which is exactly the position you want to be in at the moment something breaks in production.
Questions people ask while a live app is broken
There are three speeds. A fix on your own server or behind a remote config switch is live in minutes and touches no store. An over the air update is minutes to publish and reaches each user on their next app launch, but only if the build they installed already contains an update client and the fix is JavaScript, styling or an image. Anything native means a new binary and a review: Apple's App Review page, read on 10 October 2026, says review typically covers at least 50 percent of submissions in less than 24 hours and 90 percent in less than 48 hours, while Google Play Console Help puts processing at a few hours up to seven days, or longer in exceptional cases.
Decide your hotfix route before you need it
Know which switches you can flip without a release, whether your build can take an update over the air, and who in your team can reach Halt rollout and Pause Phased Release. That half hour of preparation is worth more than any speed you can buy during the incident itself.
Start building