$ cat choices/react-native.md
the call
I reach for React Native, by way of Expo, when one team has to cover iOS, Android, and the web from a single codebase, and the org can't yet justify a native team per platform. Shared velocity over native polish, on purpose. And the price of that trade keeps dropping. I still don't reach for it when the product lives or dies on platform-native feel.
React Native lets one team cover every screen your users are on instead of standing up, staffing, and syncing a separate team per platform building the same product over and over. iOS and Android are the obvious two. With react-native-web (which Expo bundles) the same codebase renders the web app too, so it’s really three platforms from one team. Windows and macOS exist as community-supported targets on top of that. When the bottleneck is headcount and reach, not the last 10% of native feel, a shared codebase turns three or four roadmaps into one.
Two things make this a much better bet than it used to be. First, reach for Expo, not bare React Native. The toolchain, EAS build/submit, and the managed native layer are now the sane default; rolling your own is a tax most teams shouldn’t pay. Second, OTA updates. With Expo’s over-the-air updates you ship JS and asset fixes straight to users without an app-store round-trip. Fix a bug at 2pm, it’s live by 2:05. Almost nothing else in mobile gives you that; native makes you wait on review for every change.
If the product’s whole value is platform-native feel, the gestures and micro-interactions users can’t name but feel instantly, native is still the right call and you should take it. It’s also wrong as a default just because it’s familiar: the org has to genuinely not be able to justify two native teams yet. The old reflexive knock, “the bridge is a perf ceiling,” no longer holds (see below), so the honest version of “when I don’t” is narrower than it was.
At GigSmart we shipped two React Native apps from zero to two in eight months with a single team, instead of standing up two native teams the org couldn’t yet justify. A deliberate trade: shared velocity over native polish. One codebase, one team, both platforms, reach on day one. The constraint was headcount, so the architecture answered headcount. I’d make the same call today, and reach for Expo to make it, because the trade is cheaper now than it was then.— see: works / GigSmart
Pick the architecture that answers your actual constraint, and re-price the trade as the tooling matures. When the thing holding you back is people and reach, optimize for shared velocity, not the purest version of the tech. React Native is the case study in why a “no” can become a “yes”: the ecosystem grew up. The New Architecture replaced the old asynchronous bridge with JSI, Fabric, and TurboModules. Bridgeless became the default in 0.76 (late 2024) and the legacy bridge was removed outright in 0.85 (2026). The single biggest historical reason to avoid RN is gone, so the cost side of the equation dropped. A good call isn’t permanent. It’s the best answer given today’s costs, and you owe it a re-check when those costs move.
the gaps — what it costs even when it’s right
The native ceiling is lower, not gone. JSI killed the bridge bottleneck, but the hard 10% (deep platform integrations and the surfaces that have to feel exactly right) is still where you spend the savings you banked early.
You’re now hostage to the ecosystem keeping up. The flip side of the New Architecture: removing the old bridge broke any library that still wrapped native code the old way. You’re betting that the third-party modules you depend on ship New-Architecture-compatible versions, and some won’t, on your timeline.
OTA is a loaded gun. Shipping straight past review is the feature and the risk. It’s how you fix a bug in five minutes, and how you push a bad one to everyone in five minutes. It needs the same guardrails as any deploy path: staged rollout, the ability to roll back, and a human who can tell a “move fast” change from a load-bearing one.
used at
works / GigSmart