Hot reload, hot update, OTA, in-app updates: React Native's most confused terms
Four different mechanisms, one overloaded vocabulary. A short disambiguation of what changes, where it runs, and who it's for — so you can stop talking past your teammates.
Search for "react native hot update" and half the results are about a development feature, half are about production update delivery, and a few are about Google Play prompting users to install a new binary. These are four unrelated mechanisms sharing two words. Here's the map, shortest useful version.
1. Hot reload / Fast Refresh — development only
The thing that updates your simulator the moment you hit save. Fast Refresh (the modern name) swaps edited modules into the running dev app and often preserves component state. It exists only when connected to the Metro dev server; nothing about it ships to users, and it has no production equivalent. React Native documents the exact Fast Refresh behavior. If someone says "hot reload" about production, they mean one of the next two.
2. OTA updates (a.k.a. "hot updates", code push) — production JavaScript delivery
The subject of most of this blog: shipping a new JavaScript bundle to installed apps without shipping a new native binary. The installed native binary stays identical; the exact download and apply timing depends on the client configuration. This is what CodePush was, what EAS Update and BetterCodePush are, and what many tutorials call a "hot update." It changes JS and assets only; the native/JavaScript boundary defines exactly what it can and can't touch.
3. In-app updates — prompting users to install a new binary
Google Play's in-app updates APIdoesn't deliver code at all. It's UX around the store's update: the app can offer an immediate or flexible update flow. iOS has no equivalent system API; teams use their own prompt patterns there. The new version still went through review; this mechanism just fights update procrastination. Useful in combination with OTA: in-app update prompts move users to new binaries, OTA keeps each binary's JavaScript current between them.
4. Store auto-updates — the default everyone forgets
Absent everything above, users get new versions through the store's auto-update settings and device conditions. That creates fleet lag: old binaries can remain active after a release. This is why OTA update targeting exists (old binaries need compatible bundles) and why "just ship a store update" can be slower than it sounds even after review clears.
The cheat sheet
- Fast Refresh: your machine, dev only, seconds.
- OTA update: your users' JS and assets, subject to store policy and client configuration.
- In-app update prompt: nudges users onto a reviewed binary.
- Store auto-update: a store-delivered binary on the user's schedule.
Four lanes, four speeds. Most healthy React Native release setups actively use the last three — and never confuse them in a postmortem again.