React Native in 2026: What Changed, and When I Still Recommend Native or Flutter

The short answer

For most startups and business apps in 2026, I recommend React Native with Expo: one TypeScript codebase for iOS and Android, logic shared with a React web app, small fixes shipped without waiting for app review, and an architecture that no longer carries the performance caveats it had a few years ago.

I still recommend native Swift and Kotlin when the app's main value is a platform feature, and Flutter when the team already writes Dart or the product is a heavily custom-drawn interface. Those are real cases, but they are the minority of the apps founders ask me about.

What changed since "React Native is slow"

Most of the criticism you will read about React Native describes an architecture that no longer exists.

• The New Architecture is now the only architecture. It became the default in React Native 0.76 (October 2024) and the only option from 0.82 (October 2025). JavaScript now talks to native code directly through JSI instead of an asynchronous bridge, with a new renderer (Fabric) and lazily loaded native modules (TurboModules). Synchronous layout and React's concurrent features work as they do on the web.
• Hermes V1 is the default JavaScript engine since 0.84 (February 2026).
• React 19.2 and the React Compiler. Current versions run React 19.2, and React Compiler 1.0 (stable since October 2025) works on React Native, removing most of the manual memoisation that used to separate fast apps from slow ones.
• Expo is the recommended way to start. The React Native docs now say that most developers benefit from using a framework like Expo. Expo SDK 57 (June 2026) ships React Native 0.86; the current React Native release is 0.87, with 0.88 in release candidates.

Comparing the options

When I still recommend native

• The platform feature is the product. Heavy camera and AR work, continuous Bluetooth hardware connections, watch-first or widget-first experiences, and games.
• You already have strong iOS and Android teams. Rewriting the way a capable team works rarely pays off.
• The app is small, single-platform and long-lived. An internal iPad app for one company does not need cross-platform anything.

When Flutter is the better fit

• Your team already knows Dart, or your agency is a Flutter shop with a track record.
• The design is entirely custom and must look identical on every platform. Flutter draws every pixel itself, and its Impeller renderer is now the only renderer on iOS and the default on modern Android.

Over-the-air updates: useful, with rules

EAS Update can push JavaScript, styling and image changes to installed apps without a new store release. That is how a typo or a broken screen gets fixed in minutes instead of days. It cannot change native code, permissions or the SDK version; those still go through the stores.

Both stores allow this within limits. Apple's developer agreement permits downloaded interpreted code only if it does not change the app's primary purpose or bypass the operating system's security, and Google Play's policy makes a similar exception for code run in an interpreter, such as JavaScript. In practice: use updates for fixes and small improvements, and ship new features through review.

Store requirements to plan for

• Google Play target API level. New apps and updates must target Android 16 (API level 36) from 31 August 2026, with extensions available until 1 November 2026. Current React Native and Expo versions handle this, which is one more reason not to start on an old template.
• 16 KB memory pages. Google Play requires apps to support devices with 16 KB memory pages. React Native supports it from 0.77, but older native libraries may not; check the current deadline in the Android documentation, because it has moved before.

How I would start a new app today

1. Expo, TypeScript and Expo Router, created with create-expo-app, so navigation, deep links and the web build come from the same files.
2. EAS Build and Submit for store builds, and EAS Update for fixes.
3. Check every dependency on React Native Directory for New Architecture support before adding it, and prefer Expo's own modules where they exist.
4. Write native code only when a feature needs it, as an Expo module, so the rest of the app stays in TypeScript.
5. Ship the web version first if you are still validating the idea. A web app needs no review and no install, and moving the proven flows into the mobile app is cheap when both share the same code.

Thinking about a mobile app? See Idea to launch for how I take an idea to a first version in weeks, or email devusamaworks@gmail.com or WhatsApp +92 303 8004684 for a free 30-minute call.