Your first production bug is a distribution problem before it is a code problem.
The fix is the easy half. The hard half is that your app is sitting on other people's phones and you cannot reach it. So the first hour goes on two questions: how many people does this touch, and is it still spreading. Google Play lets you stop the spread in a couple of clicks. Apple lets you ask for a faster review. Neither lets you reach into a phone that already updated. Every figure and screen name below comes from Apple's and Google's own help pages, read on 16 October 2026.
What follows is the order to work in, what each store actually lets you do about a bad build, who qualifies for an expedited review and what Apple does and does not promise, and the one lever Android has that iOS does not.
Start hereThe short version
Stop the spread, then fix the code, in that order.
Shipping is not like deploying a website. There is no single copy to correct. There are thousands of copies, each on a phone, each updating when its owner lets it. That is why the first move is never a code change. It is a distribution change: halt the rollout on Google Play, pause the phased release on the App Store, or turn off the server endpoint that is feeding the fault.
Then the fix goes through review like any other build. Apple is fast and has a documented way to ask for faster. Google is slower and gives you something better instead, which is the ability to take the bad version out of circulation. Knowing which of those two you have, before anything breaks, is most of the skill.
What do you do in the first hour?
Count, then contain, then fix. Counting means getting past the one angry review that told you about it. How many sessions crashed, on which app version, on which operating system version, in which country. One device model on one old release is a different problem from every launch failing. Most people skip this step and spend the afternoon on a fault that was only ever hitting four phones.
Containing means asking where the fault actually lives. If the broken value arrives from your own API, the app is innocent and you can fix it in minutes without going near a store. If the app itself is wrong, you cannot patch what is installed, so the lever is distribution. Halt the rollout on Play. Pause the phased release on the App Store if one is running. Turn off the feature flag if you had the sense to put one in.
Only then do you write the fix, and the discipline is to change one thing. A bug fix that also brings a redesign is no longer a bug fix: it is a new submission with new ways to fail review. Keep it narrow, bump the build, and know the odds you are up against before you promise anyone a date. Published rejection rates are the context for how safe a rushed build really is.
Severity is not about how bad the code is. It is about what it costs per hour. A crash on a settings screen costs almost nothing. A purchase that fails silently costs money, trust and a refund queue, which is why anything touching app monetisation gets triaged above a louder but cheaper crash. Write that scale down once, while nothing is on fire, and you will not have to argue it with yourself at midnight.
Triage it
What is the bug actually doing to people?
Pick the one closest to yours. The answer is the first move, not the fix.
Nothing picked. Start with what a customer would say about it, not with the stack trace.
Can you pull a bad release back?
On Google Play, to a useful degree. Halting a staged rollout stops the spread: Google states that no additional users will receive that version, and that users who already received it remain on it. If the bundle turns out to be fine you select Manage rollout and then Resume rollout, set a percentage and confirm. If it is not fine, Google's own instruction is to create and roll out a new release with a fixed app bundle.
The stronger case is a release that already reached everyone, and Play covers that too. Halting a fully rolled out release prevents new and existing users from installing or updating to the affected version, and a previously live fully rolled out version takes its place for new and eligible users. It works on any track except internal testing, from the web console, the mobile console or the Publishing API. Two limits are worth reading before you rely on it. You cannot halt the first release on a track, because there is no earlier version to fall back to. And Google says halting may not help much once a release has been live a long time or has reached a large share of users, since most of them have already updated.
The App Store is thinner here, and this surprises people who came from the web. App Store Connect Help documents phased release, which sends an update to a random sample of users with automatic updates on eligible devices across seven days, at 1, 2, 5, 10, 20, 50 and 100 percent. You may pause that release for up to 30 days in total, with no limit on the number of pauses, so ten days paused leaves twenty. You can also click Release to All Users at any time once the version is Ready for Distribution. What is not documented is a way to put the previous build back. Pausing stops the wave. It does not reverse it, and anyone can still download the version manually from the App Store while it is paused.
The practical lesson is to run the gradual rollout on both stores every time, even for small updates. It is the only thing that turns a bad build into a small incident instead of a total one, and it costs you nothing but patience. The fix itself ships as a fresh build, so get the version numbers right before you upload. A rejected or duplicated build number is a needless hour when you do not have an hour.
Google Play Console Help, halting a fully rolled out release, read 16 October 2026
Who qualifies for an expedited review?
Anybody can ask, and that is the whole eligibility test. Apple states that App Review works around the clock with the goal of reviewing at least 50 percent of submissions in less than 24 hours and 90 percent in less than 48 hours, and that if you are facing extenuating circumstances, such as fixing a critical bug or timing your release to coincide with an event, you can request an expedited review. Read that twice before you ask for one. The normal queue is already fast, so for most bugs the request saves you a few hours and spends goodwill you may want later.
The order of operations catches people. You submit the app for review in App Store Connect first, because only submissions that have already been sent to App Review can be expedited. Make it ready at that moment: all required information in the Notes field, and a demo account or demo mode for anything behind a login. For a critical bug fix, Apple asks you to include that information in the Notes field when you submit. Then you go to the Request an Expedited App Review form, select the app and the platform, and submit. Apple says App Review will evaluate your request and expedite the app's review as allowed by availability and demand, and adds that expedite requests should be reserved for matters of genuine urgency.
What Apple does not do is define a critical bug. There is no list of qualifying faults, no threshold of affected users and no promise attached to the request. It is a case you make to a person, so the Notes field should read like an incident report: what customers experience, on which version, and the steps to reproduce it on the build that is live right now. No adjectives. The fastest expedite requests are the ones a reviewer can confirm in two minutes.
Plan for the request to fail, and for the build to come back. An urgent submission gets an ordinary review, so the same missing demo account that fails a normal build fails this one, except now the bug is still live while you argue. If it is refused on something you think is wrong, appealing a rejection is usually faster than reuploading and starting the queue again.
Apple, App Review Help, request an expedited review, read 16 October 2026
Does Google Play have a fast track?
No, and it is better to know that in advance than to go looking for the button at the worst moment. The Play Console Help page on publishing your app describes standard publishing, where updates are processed and published as soon as possible, and it warns that for certain developer accounts Google takes more time to review, which may result in review times of up to seven days or longer in exceptional cases. Nowhere does it offer an expedited or faster review request. There is no form, so there is nothing to fill in.
That sounds worse than it is, because the two stores solved the same problem from opposite ends. Apple reviews quickly and lets you ask for quicker. Google reviews on its own schedule but hands you the distribution switch, so you do not have to wait for anybody to stop the damage. If you take one habit from this page, take that one: on Android, halting comes first and the fix comes second, because halting is instant and the fix is not.
Two things make the Android wait shorter in practice. Keep the change tiny, because a hotfix that only touches the broken path is the least interesting thing a reviewer will see that day. And do not keep submitting. Uploading another bundle on top of one in review replaces what is being looked at, which feels like progress and usually is not. Decide, upload once, and leave it alone.
Then plan the release so a bad build is never at 100 percent on day one. Roll out to a slice, watch your crash rate against the previous version for a day, and only then open it up. On Play that also keeps halting useful, because halting works best while most people have not updated yet. Gradual rollout is the cheapest insurance in mobile and almost nobody new to shipping uses it.
Google Play Console Help, halting a fully rolled out release, read 16 October 2026
What each store lets you do about a bad build
| What you need | App Store | Google Play | Same on both |
|---|---|---|---|
| Slow a release down on purpose | Phased release: 1, 2, 5, 10, 20, 50 then 100 percent over seven days | Staged rollout, you choose the percentage | Yes |
| Stop a rollout that is in progress | Pause it, for 30 days in total, with no limit on the number of pauses | Halt rollout, and no additional users receive that version | Yes |
| Pull back a release already at 100 percent | Not documented | Halt rollout, and the previous version takes its place | No |
| Push a fix to everybody at once | Release to All Users, once the version is Ready for Distribution | Resume the rollout at any percentage you like | Yes |
| A documented way to ask for a faster review | Yes | No | No |
| Roll a phone back that already updated | No | No | Yes |
Read from Apple's App Review Help and App Store Connect Help, and from Play Console Help on staged rollouts, halting a fully rolled out release and publishing your app, on 16 October 2026.
Where this lands if a builder generated your app
It changes who can fix it, not what the stores allow. Both queues treat a generated app like any other app, and on iOS you are the one who presses submit anyway: App Store Review Guideline 4.2.6 rejects apps created from a commercialised template or app generation service unless they are submitted directly by the provider of the app's content. So the expedite request, the Notes field and the halting are all yours.
What matters at this point is whether you can get at the code. Newly generates a real React Native and Expo project you own, with two way GitHub sync, which means a production bug is a normal pull request on a normal repository. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK, so the path from a one line fix to a new build is the same path you used to launch. It is $25 a month, with no free tier. If your builder cannot hand you the source, your worst hour will be spent waiting for somebody else.
The honest limit: no builder shortens a store review, halts a rollout for you or decides whether your bug is critical. Those are console actions on your account, and they are the ones that matter in the first hour. Describing the fix in plain English is quick. Knowing which switch to pull while it builds is the part worth learning before you need it.
Questions people ask about their first production bug
Work out how many people it reaches and whether it is still spreading, then stop the spread before you write any code. On Google Play that means halting the rollout, which stops new and existing users installing or updating to that version and puts the previous fully rolled out version back in front of new installs. On the App Store you can pause a phased release, but if the version is already at 100 percent there is no documented way to put the old build back. Only after that do you look at the stack trace, because the fix has to go through review either way.
Build it so the first bug is survivable
Own the code, roll out gradually, and know which switch each store gives you. Then your first production bug is an afternoon, not a week of waiting for somebody to answer an email.
Start building