Flutter vs React Native vs Native in 2026: How to Choose

If you are choosing a mobile stack in 2026, the short answer is: use React Native with Expo if your team already writes TypeScript and the app must feel native; use Flutter if you want one rendering engine across mobile, web and desktop or your team comes from Dart, Java or C#; use Kotlin Multiplatform if you have Android engineers and want native UIs with shared logic; and go fully native in Swift and Kotlin when the product depends on deep OS integration. The rest of this article explains how to tell which of those four you are.

The four realistic options in 2026

The "Flutter vs React Native" debate is out of date as a two-way choice. There are four serious paths now, and they differ on one fundamental axis: who draws the pixels and where the business logic runs.

Flutter compiles Dart ahead of time to native code and draws every pixel itself with its own engine (Impeller is the default renderer on iOS and Android). The OS provides a surface; Flutter does the rest. That is why a Flutter app looks the same on every device and why it extends naturally to web, Windows, macOS and Linux.

React Native runs JavaScript or TypeScript on the Hermes engine and renders real platform widgets. With the New Architecture, JavaScript calls native code synchronously through JSI, layout goes through Fabric, and native modules are typed TurboModules. The old asynchronous bridge, the source of most historical performance complaints, is gone. Expo is now the default way to create and ship a project: it provides the build service (EAS), over-the-air updates, file-based routing with Expo Router, and a curated set of native modules. Config plugins let you add native code without leaving Expo.

Kotlin Multiplatform (KMP) is the rising third option. You write networking, persistence, domain rules and view models once in Kotlin and compile them to a JVM library for Android and a native framework for iOS. UI can stay fully native (Jetpack Compose on Android, SwiftUI on iOS) or be shared with Compose Multiplatform, which is stable on iOS. Google recommends KMP for sharing logic between Android and iOS, and JetBrains ships the tooling.

Native means Swift with SwiftUI on iOS and Kotlin with Jetpack Compose on Android. Two codebases, two teams or one team with two skill sets, and no abstraction between you and the platform.

Flutter vs React Native vs KMP vs native: comparison table

Criterion	Flutter	React Native (Expo)	Kotlin Multiplatform	Native (Swift / Kotlin)
Language	Dart	TypeScript / JavaScript	Kotlin (+ Swift for iOS UI)	Swift, Kotlin
Rendering	Own engine (Impeller); draws every pixel	Native platform widgets via Fabric	Native UI, or Compose Multiplatform (Skia-based)	Native UI toolkits
Native look and feel	Consistent across platforms; platform styling must be emulated (Material / Cupertino)	High; real UIKit / Android views	High with native UI; medium with shared Compose UI	Highest
Performance profile	Predictable AOT code and GPU-driven rendering; large binary	Near native for UI; JS thread can bottleneck heavy computation	Native for logic; UI performance equals the toolkit used	Best ceiling, most predictable
Access to platform APIs	Through plugins and platform channels	Through TurboModules / Expo modules; config plugins for native config	Direct on each platform (expect/actual)	Direct, day one of each OS release
Web / desktop reach	Strong: web, Windows, macOS, Linux from one codebase	Web via React Native Web / Expo; desktop is community-supported	Desktop via Compose; web is experimental	None without a separate project
Hiring pool	Medium; Dart is rarely a first language	Largest; every web team knows React	Medium; strong in Android shops	Medium; specialists cost more, two skill sets
Tooling maturity	Mature: hot reload, DevTools, first-party IDE support	Mature: Expo CLI, EAS, Metro, React DevTools	Maturing quickly; iOS side still relies on Xcode plus Kotlin tooling	Most mature: Xcode, Android Studio
App size (order of magnitude)	Tens of MB baseline (engine bundled)	Tens of MB baseline (Hermes + runtime)	Close to native; shared library adds a few MB	Smallest; single-digit MB for simple apps

The table shows the pattern: every layer you put between your code and the OS buys you reach and speed of delivery and costs you fidelity and access. The question is never "which is best" but "which trade-off does this product tolerate."

Performance in practice, not in benchmarks

Most benchmark articles measure list scrolling or startup on a flagship phone and conclude that the differences are small. On a mid-range Android device, which is what most of your users outside Western Europe and the US are holding, the picture is more nuanced.

Startup: native apps start fastest. Flutter and React Native both add a runtime initialization step that costs hundreds of milliseconds on low-end hardware; Hermes bytecode and Flutter's AOT builds keep that penalty bounded.

Rendering: Flutter controls the whole pipeline, so animations are consistent but shader compilation used to cause first-run jank; Impeller was built specifically to eliminate that. React Native renders native views, so a FlatList or FlashList is as smooth as the platform allows, but any work you do on the JavaScript thread competes with UI updates. Move heavy work to native modules or worklets (Reanimated runs animations on the UI thread for this reason).

CPU-bound work: image processing, encryption, on-device ML inference. Flutter can use isolates and FFI to C; React Native needs a native module or a JSI-bound C++ library; KMP and native just call the platform. If your core loop is CPU-bound, count that as a point for KMP or native.

Measure before deciding: build your heaviest real screen on two candidate stacks and run it on the cheapest device your analytics shows.

When native is non-negotiable

Cross-platform frameworks can reach any OS API through a native module. The honest question is how much of your app will be native modules. When the answer is "most of the differentiating features," you should be native from the start.

• Camera pipelines and AR. ARKit and ARCore, custom camera controls, real-time filters, depth sensing. Plugins exist, but they lag behind OS releases and expose a subset of the API.
• Home-screen and lock-screen widgets, Live Activities, App Intents. These run outside your app process in platform-specific frameworks (WidgetKit, Glance). They are native code regardless of your main stack.
• Wearables. watchOS and Wear OS apps are separate targets with their own UI frameworks and strict resource limits.
• CarPlay and Android Auto, TV platforms. Template-based native frameworks with review constraints.
• Background execution. Audio playback, VoIP, location tracking, Bluetooth peripherals, health data sync. Feasible cross-platform, but the debugging happens in native code and the OS rules change every year.
• Security-sensitive features. Secure Enclave, StrongBox, passkeys, hardware attestation. Native APIs first, wrappers later.
• Day-one adoption of new OS features. If your marketing depends on shipping the new iOS feature the week it launches, you cannot wait for a plugin.

A rule of thumb: if more than roughly a third of your roadmap lives in the list above, cross-platform saves you little and adds a layer to debug. Go native, or use KMP to share the logic and keep the UI native.

Team and hiring considerations

The stack you can staff beats the stack that benchmarks best.

Existing web team. React Native with Expo is the lowest-friction path. React mental model, TypeScript, npm, the same state-management patterns you already use. Expect a learning curve around native build tooling, signing and store submission, which EAS hides for the common cases. If you have already invested in TypeScript, that investment carries over completely.

Existing Android team. KMP is the natural extension. Kotlin engineers keep their language and share the code that is boring to write twice. The iOS side still needs someone comfortable in Swift and Xcode, at least for UI and platform integration.

Greenfield team, no strong prior. Flutter and React Native are both reasonable. Flutter's advantage is a single, opinionated toolchain and no dependency on the npm ecosystem's churn. React Native's advantage is the size of the hiring pool and the option to share code with a web app.

Agencies and outsourced teams. Ask which stack they ship most, and check the store reviews of their published apps for complaints about performance or platform feel.

Whichever you pick, budget for at least one engineer per platform who can read native stack traces, configure signing and CI, and write a native module. Every cross-platform project needs that person, usually sooner than planned. Our guide on choosing a technology stack for a startup covers the wider hiring trade-offs.

Migration and coexistence: brownfield integration

Very few teams start from zero. The realistic scenario is an existing native app, or two of them, and a question about whether the next hundred screens need to be written twice.

All three cross-platform options support running inside an existing native app:

• Flutter add-to-app packages your Flutter code as an Android AAR or iOS framework. The host app creates a FlutterEngine, optionally pre-warmed, and presents a FlutterViewController or FlutterFragment for a given route. Multiple engines can share resources through an engine group.
• React Native embeds a root view (RCTRootView on iOS, ReactRootView on Android) that the host app pushes like any other screen. Expo supports this path, so brownfield does not mean giving up the Expo module ecosystem.
• KMP is brownfield by design. The shared module is just a library; the existing Android app depends on it as a Gradle module and the iOS app links an XCFramework. Nothing about the UI changes on day one.

A migration that works follows the strangler pattern used for legacy systems: pick a low-risk, self-contained flow (settings, a help center, an onboarding survey), ship it in the new stack behind a feature flag, measure crash rate and performance against the native version, then expand. Keep the interface between host and module thin and typed: navigation, authentication token, theme, analytics. Every additional call across that boundary is maintenance you will pay for on both sides.

Two costs are easy to underestimate: app size (the first embedded screen brings the whole framework runtime with it) and navigation (two stacks produce edge cases in back-button behavior, deep links and state restoration). Decide early which side owns navigation.

Decision checklist by app type

Use the profile that matches your product. If two match, take the more restrictive one.

Consumer app (marketplace, media, fitness, social)

• Must match platform conventions closely? React Native or native.
• Brand-heavy custom UI that should look identical everywhere? Flutter.
• Web version planned from the same codebase? React Native (Expo) or Flutter.
• Growth depends on widgets, Live Activities, watch app? Native, or cross-platform plus native extensions from the start.

Internal field app (inspections, logistics, maintenance)

• Mostly forms, lists, photos, offline sync? Flutter or React Native; both handle this well and the single codebase pays off immediately.
• Rugged Android-only devices? Native Kotlin, or KMP if iOS may come later.
• Barcode, NFC, printers, external sensors? Check plugin coverage for your exact hardware before committing. See our notes on IoT application development.

B2B SaaS companion app

• Web product already in React? React Native with Expo; share types, API clients and often components with the web app.
• Product is a dashboard-style consumer of your API with occasional notifications? Consider whether a PWA covers it before building any native app.
• Enterprise customers require MDM, SSO, certificate pinning? All stacks can do it; verify the specific libraries before signing the contract.

Hardware-linked app (BLE devices, medical, automotive, smart home)

• Bluetooth Low Energy as the core interaction? Native or KMP. BLE stacks differ enough between iOS and Android that plugins hide the wrong details.
• Regulated (medical, automotive)? Native reduces the audit surface: fewer third-party dependencies to document.
• Companion UI is simple and the device does the work? Cross-platform is fine if the BLE layer is a dedicated native module you own.

Cost implications

Cost differences come from three places: how many codebases you maintain, how many specialists you need, and how much native code you end up writing anyway.

A single cross-platform codebase for an app with mostly standard UI is one build and one maintenance stream instead of two. That is the whole business case, and it holds for most consumer and business apps. The savings shrink as native module count grows, and at the extreme a cross-platform app with heavy native integration costs more than two native apps: three codebases plus the glue between them.

KMP sits in between. You share the logic (typically the larger and more bug-prone half of an app) while paying for two UIs. For teams with strong Android skills, it is often the cheapest way to get a native-quality iOS app.

Hidden costs to budget for, regardless of stack: device farm testing across OS versions, store review cycles, yearly OS migrations (both Apple and Google deprecate APIs on a schedule), and dependency upkeep. For concrete ranges on team composition and day rates in Europe, see how much custom software costs to develop in Europe. A solid CI/CD pipeline with automated builds and signing is not optional on any stack; it is the difference between a weekly release and a monthly one.

Recommendation

Default to React Native with Expo when your organization already builds in TypeScript and the app should feel native. Default to Flutter when consistent custom UI across mobile, web and desktop matters more than platform idiom, or when your team prefers a single opinionated toolchain. Choose Kotlin Multiplatform when you have Android engineers and want native UIs with shared business logic. Go fully native when the product's value lives in camera, AR, widgets, wearables, background services or hardware, or when day-one OS features are part of the strategy.

Before committing, run a two-week spike on your hardest screen with the two strongest candidates, on your cheapest target device, and decide with numbers from your own app. At Arvucore we usually recommend that spike over any amount of comparison reading, including this article.