Every six months someone writes a think-piece about React Native being dead. Meanwhile, we keep shipping apps with it. Real ones, with real users, into real app stores, on real deadlines. At some point the gap between the think-pieces and the delivery reality got big enough that it was worth writing down why.

This is an engineer’s take on React Native in 2026. What actually changed with the New Architecture, when we default to it, when we pick native instead, and where Flutter and the web fit in. Written from shipping apps, not from Twitter.

What “React Native” means in 2026

Three things have changed enough that a reasonable engineer who last looked at React Native in 2022 should update their mental model.

The New Architecture is now the default. Fabric, TurboModules, JSI, and Bridgeless mode stopped being experimental and became the shipping reality. The old “bridge” that everyone complained about in 2020 is gone. UI updates are synchronous where they need to be. Native modules are loaded lazily. Startup time and memory footprint are meaningfully better than even two years ago.

Expo is not optional. Expo is now how serious teams run React Native. EAS Build handles the build pipeline, EAS Update handles OTA updates, config plugins handle native customisation without ejecting. The days of “you have to eject Expo to do anything real” are over. We ship Expo-managed apps into the App Store with fingerprint auth, custom native modules, and heavy animations without touching Xcode most days.

Skia changed what’s possible on the UI layer. Anything genuinely graphics-heavy (game-like UIs, complex data viz, particle effects, shimmer and glow treatments) runs through React Native Skia on the GPU, not Reanimated on the UI thread. This is what closed the last real performance gap between React Native and native for the subset of apps that were bumping against it.

None of that is hype. It is just what the ecosystem is actually doing in 2026.

Why we still default to React Native

There are five reasons and they are in order of how much they matter in practice.

1. Cross-platform from one codebase, and “one codebase” now includes web

React Native for iOS and Android plus React (the same engineers, the same components, mostly the same logic) for web. For a small team with a product that needs to ship across all three platforms, this is not 3x cheaper than native + web. It is more like 1.4x the cost of shipping one platform. That delta is what pays for everything else.

Cosmetify shipped iOS and Android in parity in twelve weeks with this approach. EDF Energy’s pilot shipped in 93 days the same way. We use this stack not because it is fashionable. We use it because the economics work.

2. The hiring pool is deeper than any native pool

You can hire a strong React developer faster than you can hire a strong iOS or Android developer. The React Native learning delta for a strong React developer is two to three weeks, assuming they want to do it. A team that already knows React can also ship native mobile. A team that is entirely iOS cannot easily pick up web when the business needs it.

This matters more for fractional and small-team engagements than for large companies. Scale-ups with a dozen engineers can afford specialist iOS and Android hires. Founders with a £25k MVP budget cannot.

3. OTA updates via EAS Update change how you ship

Being able to push a JavaScript-only bug fix to users within an hour, without a two-day App Store review, is a different operational reality than native shipping. It changes how you think about release cadence, QA, and rollback. We use it carefully (the UX rules are different from server deploys) but when you need it, you need it.

Native-only teams either do not have this, or have bolted on CodePush and paid for the same capability with worse ergonomics.

4. Sharing logic with the web app is not a theory any more

A lot of business logic (validation, API clients, state management, formatting, analytics instrumentation) is genuinely shared between the web app and the mobile app when you use React Native and React together. Not “write once run anywhere” which is still a lie. More like “write the heart of the thing once and target three UIs”, which is realistic and saves real weeks.

5. The performance story is finally honest

For the 90% of apps that are “screens full of content, buttons, forms, and animations”, React Native in 2026 performs indistinguishably from native. For the 10% that is pushing against the edges (real-time AR, 3D graphics, heavy live video, professional-grade audio), it still does not.

The trick is being honest about which 10% you are in before you pick the stack.

When we don’t use React Native

The question that actually matters is not “when does React Native fall over?” but “when is the cross-platform saving smaller than the cost of working around its edges?”. In practice this shows up in four situations.

When the app is a thin wrapper over heavy native SDKs

If your product is fundamentally “we wrap this specific iOS SDK or this specific Android SDK”, use native. Examples: a professional audio workstation app, a deep HealthKit integration, a ground-up AR experience built on ARKit, anything that hooks into a kernel-level iOS capability. You will spend more time wrapping the SDK in JavaScript than you would have spent writing the whole app natively. Do the native version.

When the product is single-platform forever

If you genuinely will never ship to Android, go native iOS. SwiftUI in 2026 is mature and fast to work in. The React Native tax is only worth paying when you actually intend to ship to more than one platform.

Note: “we will be iOS-only forever” is something founders say in year one that is not true in year three. If there is any realistic possibility of Android later, pay the small cross-platform tax now.

When you have a big existing native team

A team of twelve native iOS and Android engineers does not need React Native and will slow down trying to adopt it. This is an organisational fit, not a technology fit. The economics only flip toward RN when the team is small enough that cross-platform compounding matters.

When the app is genuinely at the performance edge

Real-time video effects, on-device ML that has to hit the Neural Engine hard, frame-perfect game engines. These are genuinely better built native or with Unity/Unreal. We’ve built one native iOS app in the last three years for exactly this reason. It was the right call.

What about Flutter

This section gets the most arguments, so: clear position.

Flutter is a serious piece of technology. Dart is well-designed. The Flutter team has built an impressive rendering engine. We don’t use it.

Two reasons.

First, the hiring delta. A strong React developer learns React Native in two weeks. A strong React developer learns Flutter in two to three months because Dart is a new language and the paradigm is different. When your business needs to scale the team from two engineers to six, React Native is easier to hire for.

Second, the web story. Flutter Web exists. It does not feel like a proper web app in the way a React app does. For teams that need a proper web presence alongside mobile, React Native plus React wins. For teams that are mobile-first and mobile-only, Flutter is competitive. We end up in the first category more often than the second.

If we were building mobile-only greenfield with a five-engineer team that already knew Dart, we would consider Flutter seriously. We have not had that combination come up yet.

What about the web

The question behind this is usually: should we just build a Progressive Web App instead of going native?

The answer is: sometimes, and the test is honest.

Build a PWA when: your users will access it from a browser most of the time, you don’t need push notifications on iOS (still poor in 2026 compared to native), you don’t need background location, and you don’t need the marketing and distribution power of the App Store listing.

Build a native or React Native app when: your users expect an app store presence, you need anything from the native OS that PWAs can’t reach cleanly (biometrics, HealthKit, deep camera work, offline-first with sync, push that actually works on iOS), or the business value of “tap the icon on the home screen” is real.

The middle ground (“ship a PWA wrapped in a native shell”) is almost never the right answer in our experience. Either commit to a real cross-platform app or commit to the PWA. The hybrid usually gets the worst of both.

The performance question, honestly

Every conversation about React Native eventually lands on performance. Here is the honest answer in 2026:

The feeling that React Native is slower than native is largely a 2019 memory. The current architecture is different enough that the old intuitions do not apply.

One caveat worth stating. React Native performance is still easier to get wrong than native performance. You can write a React Native app that feels janky without trying. The ceiling is native-equivalent; the floor is lower. This is why a senior engineer who knows the performance patterns matters more on an RN build than on an equivalent native one.

How we decide

Before starting a mobile build, we run this four-question check:

  1. How many platforms? If more than one (including web), React Native plus React is the default.
  2. Does the app push native hardware limits? If yes (AR, ML on-device at scale, real-time video or audio), go native.
  3. What does the team look like? Small or hybrid team, RN. Big existing native team, stay native.
  4. Is there a genuine chance of a second platform later? If yes, pay the cross-platform tax now. If no, go native iOS.

For the majority of the builds we’ve scoped in the last two years, that check lands on React Native. Not because we are a React Native shop but because the economics of the answer genuinely point that way for most mobile products.

Where Walsh London fits in

We ship React Native builds as part of the MVP Kickstart (£25,000 for twelve weeks, cross-platform) and as part of smaller scoped builds (from £8,000 for single-platform focused work). We also rescue React Native codebases from previous agencies where the New Architecture was never adopted, which is more common than it should be.

Native iOS or Android work is quoted on the specific need, usually as a native module plugged into an otherwise-React-Native app rather than a full native rebuild.

All prices shown are exclusive of VAT where applicable.

The short version

React Native in 2026 is:

The think-pieces that declare it dead every six months continue to be wrong for the same reason: they compare it to its 2019 self, not its actual state now. The architecture is different. The tooling is different. The performance is different. The conversation ought to update too.