Flutter vs React Native in 2026: what changes when you need native code

Most "Flutter vs React Native" posts compare benchmarks. On real client projects the decision usually comes down to something more boring: what happens on the day you need a device feature that no package covers, and who on your team can write that code.

This post walks through how each framework renders, how each one talks to native code, and where each one stops being a good fit. Everything here is taken from the projects' own documentation, linked at the end.

How each one gets pixels on screen

Flutter paints everything itself. Its architectural overview says Flutter bypasses the platform's UI widget libraries in favour of its own widget set. The painting code is compiled to native machine code for release builds and rendered by Impeller, the engine shipped inside your app. Material and Cupertino widgets are just Flutter widgets that look like the platform.

React Native maps components to real platform views. At runtime a <View> becomes an Android View or an iOS UIView. Your button is a native button.

What this means in practice:

• A pixel-identical design across iOS and Android is easier in Flutter, because one engine draws it.
• Platform conventions (text selection, scrolling physics, accessibility behaviour of system controls) come more naturally in React Native, because you are using the platform's own components.

Neither is "better". Pick based on whether the product needs one brand look everywhere or an app that feels native on each OS.

The bridge is gone in React Native

If your mental model of React Native is still "JavaScript talks to native over an async JSON bridge", it is out of date. The New Architecture has been enabled by default since React Native 0.76. It replaces the bridge with the JavaScript Interface (JSI), so JavaScript can hold references to C++ objects and call native methods without serialising every call.

The docs are honest that switching it on does not automatically make every app faster. It removes a class of bottlenecks; it does not fix a slow list or a heavy re-render.

React Native also ships with Hermes as the default JavaScript engine, and new projects target TypeScript by default.

Writing native code: platform channels vs Turbo Native Modules

This is the part that matters when a package doesn't exist or is unmaintained.

Flutter: platform channels (and FFI)

You send messages over a named channel. The Dart side:

import 'package:flutter/services.dart';

const channel = MethodChannel('com.example.app/battery');

Future<int> batteryLevel() async {
  final int level = await channel.invokeMethod('getBatteryLevel');
  return level;
}

On Android you register a handler for the same channel name in Kotlin; on iOS, in Swift. Messages are encoded with a standard codec, so you are passing simple types, lists and maps across.

For C libraries, dart:ffi lets Dart call C APIs directly without a channel. For complex native UI (maps, web views), Flutter can embed platform views, which its docs note carry some performance cost.

React Native: Turbo Native Modules with Codegen

You describe the interface in a typed spec, and Codegen generates the glue:

// NativeBattery.ts
import type {TurboModule} from 'react-native';
import {TurboModuleRegistry} from 'react-native';

export interface Spec extends TurboModule {
  getBatteryLevel(): Promise<number>;
}

export default TurboModuleRegistry.getEnforcing<Spec>('NativeBattery');

You then implement NativeBattery in Kotlin or Java for Android and Objective-C or Swift for iOS against the generated interfaces. The typed spec is the nice part: a mismatch between JS and native shows up at build time rather than as a runtime crash.

Which is easier for a small team?

• If the team already writes TypeScript and React, the Turbo Module spec is familiar, and only the native implementation is new.
• If the team is new to both, Flutter's channel model is simpler to grasp, but you are learning Dart as well.

Either way, someone must be comfortable reading Kotlin and Swift. Budget for it on any app that touches Bluetooth, background location, payments SDKs or a vendor's native SDK.

Web and desktop: read the fine print

Flutter officially supports Android, iOS, web, Windows, macOS and Linux. Its own web FAQ says Flutter web suits app-like experiences (SPAs, PWAs) and is not a fit for static, text-heavy sites, and it recommends plain HTML for marketing pages because of search indexing. Don't plan to ship your SEO landing pages from the Flutter codebase.

React Native itself targets Android and iOS. Windows, macOS and web (via React Native Web) are out-of-tree platforms maintained by partners and the community. The React Native team recommends starting new apps with a framework such as Expo, which covers Android, iOS and web.

When to skip both and go native

Two codebases (Swift/SwiftUI and Kotlin/Jetpack Compose) are worth it when:

• you ship on one platform only;
• you need new OS features on release day;
• the core feature is heavy graphics, audio or background processing;
• you already employ iOS and Android engineers.

A quick decision checklist for an MVP

1. List the five features the first version can't launch without.
2. For each, write down the device APIs it needs.
3. Check that a maintained package exists for each API in both ecosystems (last release date, open issues, platform support).
4. Prototype the riskiest one (camera processing, real-time maps, background sync) in a day or two before committing.
5. Pick the framework that matches the skills you can actually hire for.

If you'd rather have a team that has shipped both talk it through, Dzimark's mobile app development team builds Flutter, React Native and native apps for clients in the USA, UK, Canada and Australia.

FAQ

Is React Native still using a bridge?
Not by default. Since 0.76 the New Architecture (JSI, Fabric, Turbo Native Modules) is on by default.

Can Flutter call C code directly?
Yes, through dart:ffi, without going through a platform channel.

Is Flutter good for a marketing website?
Flutter's own docs say no: it is meant for app-like web experiences, and static text-heavy pages should be plain HTML.

Do I still need native developers with a cross-platform framework?
For most production apps, at least part-time. Any SDK without a maintained package means writing Kotlin and Swift.

Sources: Flutter architectural overview; Flutter supported platforms; Flutter web FAQ; Flutter platform channels; React Native "About the New Architecture"; React Native Turbo Native Modules; React Native Using Hermes; React Native Out-of-Tree Platforms.

Originally published on the Dzimark blog.