CONCEPT Cited by 1 source

Hot-reloading devloop¶

Hot-reloading devloop is the developer-experience property where code changes become visible in a running application within sub-seconds of saving the file, with no compile step, no app restart, and no loss of application state. In mobile application development it's the load-bearing React Native-over-native differentiator on the developer-experience axis.

The failure mode hot-reloading eliminates¶

Native mobile development (iOS: Swift / Objective-C; Android: Kotlin / Java) has minutes-scale build-and-run cycles on large apps:

"Given the size of our code bases, it took several minutes for even the most trivial changes to be compiled and run on an emulator/physical device. This wastes time and breaks developer flow." — Mustafa Ali, Shopify

Two costs stack:

Wall-clock latency. Minutes-per-change multiplies across the dozens to hundreds of edit-save-verify cycles a day of UI work involves. Aggregate cost measured in developer-hours-per-day, not milliseconds.
Flow breakage. Even if the developer switches to another task during the build, the context switch costs the mental state of the in-progress change — what was I doing, which element was I tweaking, does that visual match my mental model? Software is not a write-once artefact; it's an iterative search process whose quality degrades when the iteration cycle lengthens.

How React Native achieves hot-reloading¶

RN runs application code in a JavaScript runtime (Hermes by default) inside the native app process. On save, the bundler (Metro) produces a new JS bundle delta; the app replaces the loaded module graph and re-renders from the React tree root (or from the nearest state-preserving boundary for Fast Refresh, RN's refined hot-reload implementation). Native code changes still require a full rebuild; the win applies to JS / TS / React component code — the overwhelming majority of typical app edits.

Impact at consumer-app scale¶

Shopify's canonical retrospective framing:

"The ability to see your changes reflect instantly with RN has been a total game changer. This was one of our biggest pain points with native ... React Native's hot reloading completely eliminates this problem."

Hot-reloading is one of the four post-migration wins Shopify highlights (alongside write-it-once, talent portability, and maintained feature parity).

Adjacent concepts¶

Hot-reloadable configuration — concepts/hot-reloadable-configuration is the runtime- configuration analog: change config without restarting the service. Same underlying devloop win at the ops/config altitude.
Test feedback loop — concepts/test-feedback-loop is the CI / local-test-run analog: shorter test cycles restore the same flow-state property on the test-driven development axis.
Fast Refresh — RN's state-preserving hot reload implementation; edits to a React component preserve component state across the reload where possible.

Limits¶

Native module changes still require app restart + native rebuild. The devloop is fast for JS / TS / React edits only. Teams with heavy native-module surfaces partially lose the win on those edits.
Hot reload has state-consistency failure modes — some edits (changes to top-level side-effects, singleton initialisers, module-scope state) can leave the app in a state that differs from a clean start. The discipline: periodically do a clean restart to verify behaviour.
Large bundles increase reload time. Even with hot reload, an RN bundle on a large app isn't instantaneous — sub-seconds, not milliseconds. Still orders of magnitude faster than native compile.

Seen in¶

sources/2025-01-13-shopify-five-years-of-react-native-at-shopify — Mustafa Ali: "biggest pain points with native ... React Native's hot reloading completely eliminates this problem." Canonical first-party disclosure from a consumer-app-scale org that hot-reloading is the load-bearing devloop improvement RN brings over native.