React Native or fully native in 2026 — a pragmatic guide
When cross-platform is the right call, when it isn't, and how we pick for our clients. With three checklists and a cost matrix.
We've shipped React Native apps at scale and we've shipped native iOS and Android apps at scale — and we still get asked, every few months, which one a client should pick. There is no universal answer, and any team that gives you one is selling you a default rather than a decision.
What follows is the framework we actually use in 2026, after eight years of building mobile apps across both stacks. It's not a manifesto for either side — it's the same one-page decision matrix we walk through on every mobile discovery call.
The default has shifted (slightly) toward React Native
In 2020 we'd default to native unless there was a compelling reason for cross-platform. In 2026, we default to React Native unless there's a compelling reason for native. The reason for the shift isn't ideology — it's that React Native's runtime story has improved (the new architecture is stable, Hermes is the default, performance gaps are narrower) while the cost-of-talent gap has widened. Hiring two senior native engineers (one per platform) costs nearly three times what hiring one senior React Native engineer does, in any major city.
For most consumer apps and most internal tools, that economics calculation is the whole conversation. If you're building a content-driven app, a marketplace, a basic e-commerce surface, a delivery app, an LMS — React Native is right, and the savings buy you more design and product investment, which is where you actually compete.
When native is still the right call
Native earns its keep when one or more of these are true. We'll call it for native if the app needs deep camera or AR work (ARKit / ARCore APIs that bridge poorly), heavy Bluetooth Low Energy with custom GATT profiles (cross-platform BLE libraries are still flaky), watchOS or Wear OS support, custom widgets, Apple's StoreKit 2 features in detail, or platform-specific UI fidelity that React Native's UI primitives can't hit cleanly (think TikTok-grade scroll, Apple Music-grade transitions).
We'll also call it for native when the team is going to maintain the app for five plus years and already has native expertise. Don't introduce cross-platform tooling into a team that doesn't have any reason to learn it — the maintenance cost will exceed the build savings within two years.
- Deep AR / ARKit / ARCore
- Custom BLE GATT profiles or heavy Bluetooth peripheral work
- watchOS / Wear OS companion apps
- iOS widgets, Live Activities, App Clips beyond the basic version
- Platform-specific animation fidelity that drives the brand experience
- A team that already has long-term native expertise
When cross-platform is not React Native
Flutter remains a legitimate choice — especially for apps where the same UI rendering everywhere matters more than blending in with each platform's idiom. We've shipped Flutter apps; the developer ergonomics are excellent. We don't default to it for our clients because the available hiring pool in our region is smaller, and the long-term maintainability concern is non-trivial: Google's commitment to Flutter is harder to read than Meta's commitment to React Native.
Kotlin Multiplatform Mobile (KMM) is the dark-horse option for 2026. It lets you share business logic across platforms while keeping native UIs — which gives you the cost savings on shared code plus the platform fidelity on the surface that users actually see. We're using it on one greenfield project and watching it carefully.
A simple decision matrix
If you only remember one thing from this piece, remember this matrix. Score each row on a 1–5 scale, sum it. If the total is 12 or below, default to React Native. 13 to 18, it's a real conversation. 19 or above, default to native.
- How important is platform UI fidelity? (1 = doesn't matter, 5 = brand-defining)
- How deep is your hardware integration? (1 = none, 5 = Bluetooth/AR/sensors heavily)
- How long will you maintain this app? (1 = 12 months, 5 = 5+ years)
- How specialised is your team? (1 = generalist, 5 = native-only)
- How tight is your launch budget? (1 = tight, 5 = comfortable)
- Default to React Native in 2026, native when the brief demands it
- Native earns its keep for AR, deep BLE, wearables, brand-grade UI fidelity
- Flutter is legitimate; KMM is worth watching for shared-logic-native-UI apps
- Score the decision matrix instead of defaulting by ideology
There is no universal right answer. There is a right answer for your app, your team and your runway. The teams we see fail are the ones that default by ideology — "we always go native" or "we always go cross-platform" — without doing the per-project conversation. Run the matrix on your actual brief and the decision usually surfaces itself.
If you want a second opinion on a specific brief, we'll run the matrix with you in a 30-minute call. No sales follow-up unless you ask for one.
Want to talk to the team that shipped this?
We share notes, templates and a 30-minute call with no sales follow-up unless you ask for one.
