What is a hotfix?

A hotfix is a small, urgent fix shipped outside the normal release cycle, usually to repair a serious defect already affecting users in production. For mobile apps, a hotfix means either an expedited store release or an over-the-air (OTA) update, because the standard review-and-update path is too slow for a live incident.

What is a hotfix?

A hotfix is the release you didn't plan. Something serious is broken in production right now: a crash on launch, a failing payment flow, a security hole. The fix is too urgent to wait for the next scheduled release, so it ships on its own, as fast as your process allows.

That urgency is what separates a hotfix from ordinary bug fixing. A regular fix rides the next release train with everything else. A hotfix jumps the queue with the smallest possible change, and it interrupts whatever the team was doing. Most teams have defined severity criteria within their release management process, so nobody is debating what qualifies as urgent while users are staring at a crash screen.

For web teams, a hotfix is like any other deploy, just faster. For mobile teams, it's harder. The broken app binary (the compiled .ipa or .apk that users installed from the store) is already on their devices, and the replacement has to pass store review. Even after approval, the fix trickles out: automatic updates take days to reach every device, and anyone who's turned them off has to install the update themselves. We’ll be focusing on mobile specifically, since the process is more complex.

How does a hotfix work?

A hotfix follows a short, disciplined path: branch from the code that's actually in production, change as little as possible, verify the fix, and ship it through the fastest channel you have. On mobile, those channels are either a release through the store or an over-the-air update, and they have very different speed limits.

The classic Git flow looks like this:

1. Branch from the production tag or main branch, not from your development branch, so the hotfix contains only what production already has plus your fix.
2. Make the smallest possible change needed to repair the defect.
3. Run the test suite and add a regression test that would have caught the bug.
4. Tag the hotfix branch and release through your CI workflow.
5. Merge back to both main and your development branch, so the fix isn't lost when the next regular release ships.

That flow gets the fix built, but getting it into your users’ hands is another story on mobile. A hotfix goes through App Store or Google Play review like any other release, which could take hours or even days (not great if critical functionality is down). An over-the-air (OTA) update, available to React Native through tools like CodePush (which supports vanilla React Native as well as Expo), replaces just the JavaScript and assets inside the installed app directly, so the fix reaches users in minutes without a store submission.

Automate the parts that should never depend on someone's memory at 2am. Every push to a hotfix branch should build and run the tests so you get fast feedback on each fix, and the release should be a separate workflow that a person starts once the branch is green. That way a second fix or a failed test never becomes an accidental store submission.

Why hotfixes matter for mobile development

Every hour a production defect stays live in a mobile app, it costs you store ratings first and revenue soon after. The teams that recover fastest are the ones that have a hotfix path rehearsed and ready to go when they need it.

Store review is the first constraint. Apple states that on average, 90% of submissions are reviewed in less than 24 hours, and an expedited review can be requested for critical issues. But nothing is guaranteed and hours are not minutes. Plus, review time is only half the story. After approval, the fix reaches users at the speed of store rollout and device update settings. Most devices pick it up within days; a long tail stays on the broken version for weeks, and some never update at all.

Recovery speed is one of the five metrics DORA uses to define delivery performance (DORA calls it failed deployment recovery time). The 2024 State of DevOps report separates elite teams, who recover in under an hour, from low performers, who take a week or more.. A mobile team can't hit web-grade numbers on the store-dependent path, which is exactly why the OTA path and feature flags exist.

Teams without a defined hotfix process end up having to improvise during an incident, which makes it far more likely that someone builds from the wrong branch, skips the regression test, or forgets the merge back to develop. The defect returns in the next mobile release, and now you’ve shipped faulty code twice.

Hotfix best practices

A good hotfix process is boring on purpose, and the best one is the one you rarely use. Set things up so most production problems can be switched off without a release, decide the rules before the incident, keep the change tiny, and close the loop so the fix sticks.

1. Make most hotfixes unnecessary. A feature flag used as a kill switch turns a would-be hotfix into a config change: disable the broken feature in seconds, then fix it calmly in the normal release cycle. Ship new features behind flags by default, so anything that misbehaves in production can be turned off without touching the binary. Staged rollouts do the rest of the work: if a release goes to 10% of users first, you can halt it before most people ever see the problem, and the fix ships as a normal release instead of an emergency. Crash reporting with alerting closes the gap between "it's broken" and "we know it's broken", which is often the longest part of an incident.

2. Set hotfix criteria in advance. Write down what qualifies as a critical fix: crashes above a threshold, ANRs (Android app-not-responding errors), broken purchase flows, security issues, data loss. Everything else waits on the next release cycle. Without a clear severity scale, every stakeholder's favorite bug becomes an emergency.

3. Branch from production, not from develop. Create the branch from the released tag (git checkout -b hotfix/crash-on-launch v3.14.2), so the only diff against what users run is your fix. Branching from develop drags unreleased work into an emergency release.

4. Keep the diff small and human reviewable. Fix only what's broken in production. If the release shipped with two urgent defects, both go in the hotfix, but a refactor or a "while I'm in here" improvement never does. One reviewer should be able to hold the whole change in their head. If the fix can't be that small, reach for the kill switch first and fix it properly in the next release.

5. Automate verification, keep the release manual. Set up a hotfix/* branch trigger that builds and tests every push, and a separate release workflow you start by hand once the branch is green. Keep that release workflow identical to your normal one except for the approval gates you consciously choose to skip.

6. Always merge back to develop. A common hotfix failure is the regression two weeks later, when the original fix never reached the development branch. Make the merge back to develop part of the definition of done, not a follow-up task.

Hotfix vs patch

Both words describe fixes, and you'll hear them used loosely. The useful distinction is urgency and path: a hotfix interrupts the cycle to fix something burning now, while a patch is planned corrective work that ships through the normal process.

How Bitrise handles hotfixes

Bitrise covers both mobile hotfix paths: an automated workflow for expedited store releases, and CodePush for OTA updates that skip the store queue entirely.

For the store release path, a workflow triggered by hotfix/* branches builds and tests every push, using the same Steps and the same stored certificates and secrets as your release workflow, so an emergency build is never hand-assembled on a laptop. Once the branch is green, you start the release workflow and Release Management handles the store submission. Staged rollouts belong in your normal releases, not your hotfixes: if a regular release ships with a problem, you halt the rollout while only a small percentage of users have it, and the hotfix goes out to everyone at once. The fewer users on the broken build, the less pressure on the fix.

If your app uses CodePush, you'll end up with two hotfix workflows, not one. The store release workflow above handles anything that touches native code. A second, much shorter workflow handles the OTA path: install dependencies, run the tests, bundle the JavaScript, and publish the update to CodePush. Which one you run depends on whether the defect is in native code or in JavaScript, so it helps to make that decision part of the hotfix criteria you set in advance. Both workflows can start from the same hotfix branch. Bitrise's workflow recipes cover the building blocks for each, from React Native dependency installs and tests through to store deployment.

For React Native and Expo apps, Bitrise CodePush is the fast path: you publish an update containing your changed JavaScript and assets, the CodePush SDK in the app checks for it, then downloads and applies it on the next restart. The store queue never gets involved, and users don't have to download anything. The release flow supports gradual rollouts, and the CodePush CLI can roll it back in minutes if the fix misbehaves. The free tier covers 100,000 monthly active users, so trying it costs nothing.

OTA updates have their limits. They can only change JavaScript and assets, so a crash in native code still needs a store release. And store policies have limits in place: we cover what Apple and Google actually allow with OTA updates in detail on the Bitrise blog. For everything OTA doesn't cover, the store release workflow is the fallback, which is why the two paths belong to one process.