React Native (Expo) vs native: when paying for two codebases stops making sense

Every agency that still bills by the platform will tell you the same thing: "Native is more performant, and you'll need native for the features you want." A few years ago that was a defensible position. Today it is mostly a sales position.

React Native — specifically Expo on the New Architecture — has closed the gap on both arguments to the point where the question for most product teams has flipped. It is no longer "why should we choose React Native?" It is "what is the specific reason we are paying for two teams, two release pipelines, and two of every bug?"

The pitch used to be simple: native compiles to native code, JavaScript runs in a bridge, ergo native is faster. Two changes broke that argument:

• Hermes ships ahead-of-time bytecode and a tuned GC for React Native's workload. Cold start and memory are no longer an embarrassment.
• JSI and the New Architecture replaced the asynchronous bridge with synchronous, typed calls between JS and native. The serialization tax that used to dominate benchmarks is gone.

For a product app — lists, forms, navigation, network calls, animations driven on the UI thread with Reanimated — the difference between Expo and a fully native build is, in real user testing, small enough that nobody outside the engineering team notices.

The other half of the pitch is that React Native can't reach the platform. That was true in 2017. In 2026 it is mostly false, because of two things:

• Expo Modules let you write a small Swift or Kotlin module and consume it from JS with type safety. You don't leave Expo to do native work; you extend it.
• Config plugins let that native module modify the iOS and Android projects at prebuild time, without you ever ejecting from managed Expo or hand-editing Info.plist / AndroidManifest.xml.

Between the first-party Expo SDK and the community ecosystem, ~95% of the native capabilities a product app needs are already wrapped: camera, file system, secure storage, biometrics, push, background tasks, in-app purchases, App Clips, App Intents, Live Activities, widgets, foreground services, share extensions. The remaining 5% you can build with Expo Modules in days, not weeks.

The cost case for cross-platform is rarely about the lines of code. It is about everything that wraps them.

• One team, not two. One hiring funnel, one set of conventions, one code review culture. Senior generalists stay engaged because they aren't boxed into one platform.
• One design system. A token change ships to both platforms in one PR. Two codebases means two interpretations of every design change, drifting from each other every quarter.
• One release cadence. One CI pipeline, one OTA channel via EAS Update, one changelog. Native teams that ship monthly on iOS and quarterly on Android are not unusual; users notice.
• One bug, not two reports. A regression in a shared component is fixed once. In two codebases, every bug is potentially two bugs.
• One observability story. Crash reporting, analytics, feature flags, A/B testing wired up once with a shared event schema.

When teams compare "Expo developer cost" vs "iOS + Android developer cost" and call it a draw, they are usually only counting the engineers who write the screens. The real cost lives in the second copy of everything around the screens.

There is a real list of cases where you should still go native, and an honest cross-platform advocate will tell you so:

• Games and graphics-heavy creative tools. Use a game engine; the question becomes Unity / Godot / native, not Expo vs native.
• Pro audio and video apps with sub-frame latency requirements.
• AR/VR and ML-on-device where you live inside ARKit / ARCore / CoreML APIs.
• Deep OEM integration — CarPlay/Android Auto first-class apps, watchOS complications with rich logic, accessibility apps that rebuild large parts of the system UI.
• Very long-lived enterprise apps where the buyer's procurement department will demand a native build because their RFP template says so.

If you can answer yes to any of these, native is at least worth a hard look:

• Is the app primarily a real-time graphics, audio, or AR experience?
• Does the app need a feature that depends on bleeding-edge platform APIs within months of the OS release, before any Expo wrapper exists?
• Are you shipping less than one release per quarter and don't care about iteration speed?
• Is there a regulatory or procurement reason that requires native specifically?

If the honest answer to all four is no — the case for the overwhelming majority of startup, scale-up, and product apps — you are paying for two codebases out of habit, not technical need.