I’m Mohammad Jashem — a Senior Mobile Architect with 7+ years shipping Flutter, React Native, and Expo in production. I’ve kept one Flutter app alive for seven years across three stores, I’ve built an HR platform in Flutter because Flutter was the right call for that product, and I’ve also migrated a Flutter app off Flutter when the architecture stopped fitting. So when founders ask me “Flutter or React Native or Expo for the MVP,” my answer is never “it depends.” It depends on what — and I can tell you the what in about ten minutes if you describe the product.
This is the comparison I wish someone had handed me before I spent six weeks patching a platform-view ANR I couldn’t fix in app code. It’s also the pillar behind two deeper write-ups: the engineering breakdown of real-world Flutter platform-view ANRs on Mali and PowerVR GPUs, and why we migrated Kahf Kids off Flutter. Read this first; drill into those when you need the failure-mode detail.
Quick comparison#
| Dimension | Flutter | React Native | Expo |
|---|---|---|---|
| Rendering engine | Impeller (Metal/Skia) paints its own canvas | Fabric renderer to native platform views | Same as RN — Expo is tooling on top of RN |
| Android TV / tvOS | Weak; no first-class TV target | react-native-tvos fork; Android TV works | Inherits RN; TV targets wired via prebuild |
| Platform views | Foreign view into Flutter’s renderer — GPU fence handshake (ANR risk on Mali/PowerVR) | First-class native view already in the tree — no handshake | Same as RN |
| Low-end-device perf | Excellent in-canvas; stalls on platform views | Hermes + JSI closes the gap; competitive | Same as RN; OTA hotfixes via EAS Update |
| Time-to-MVP | Excellent for conventional UI | Very fast when reusing mature native modules | Fastest path to TestFlight and Play Internal |
| When to pick | Conventional UI, render consistency, one Dart team | Existing RN codebase, fine-grained native control | New MVP, native-view-heavy flows, low-end hardware, TV roadmap |
The rest of this article is the reasoning behind each row.
The three options in 2026#
Flutter is Google’s cross-platform UI toolkit. You write Dart; the engine paints its own pixels with Skia (and now Impeller on iOS and Android); iOS, Android, Web, and desktop render identically because the framework doesn’t ask the platform for its native widgets — it draws them itself. Backed by Google, used in production by BMW, ByteDance, and Alibaba. In 2026 it’s mature: null safety shipped years ago, Impeller is the default mobile renderer, and the talent pool is real, though the senior architect end is still thin.
React Native is Meta’s cross-platform framework. You write JavaScript or TypeScript, and RN renders to actual platform views — UIView on iOS, View on Android — driven from a JS runtime. The 2024+ “new architecture” (Fabric renderer, Hermes engine, TurboModules, JSI) replaced the legacy bridge and closed most of the perf gap people remember from 2019. Backed by Meta, used by Microsoft, Coinbase, Shopify, and Discord. In 2026 it’s the most battle-tested JavaScript-native option.
Expo is not a third framework — it’s the tooling and managed-build layer on top of React Native. You still write RN, but Expo gives you expo prebuild for deterministic native project generation, config plugins for native behavior without touching Xcode, EAS Build/Submit/Update for cloud builds and OTA pushes, and a curated module ecosystem. In 2026, “React Native built the Expo way” is the default starting point for most new RN apps; bare RN is the niche. When I say “Expo” in this article, I mean RN shipped the Expo way.
Architecture comparison#
The rendering split is the load-bearing difference, and most comparison articles gloss it.
Flutter owns the render pipeline. Dart compiles AOT to native ARM, the engine uses Impeller (built on Metal and Skia) to draw every frame itself, and there’s no JNI hop into the platform view system for normal UI. That’s why a Flutter list scrolls at 60 or 120fps on a mid-range device where a hybrid WebView app janks: the path from your widget tree to pixels is short and single-language. The trade-off is real — anything native (a WebView, a map, a camera preview, an AR session) has to cross into Flutter through a platform view, and that crossing is where the trouble lives.
React Native (new architecture) renders to the platform’s own views through Fabric. JS runs on Hermes, calls into native through JSI (a direct C++ surface — no serialized-JSON bridge), and TurboModules are lazily initialized. The win: a map, a camera, or a WebView is already a native view in the tree, so there’s no “foreign view inside a foreign renderer” handshake. The cost: you carry the platform view-system overhead everywhere, and your business logic runs in JS.
Expo doesn’t change any of that rendering. What Expo changes is the build and release loop — prebuild generates the ios/ and android/ folders deterministically from app.json, config plugins patch native behavior without a Xcode fight, and EAS Build produces signed artifacts in the cloud. It’s a force multiplier on RN’s architecture, not a different architecture.
Short version: Flutter wins on render consistency and on UI that stays inside its own canvas; RN/Expo wins when your app’s center of gravity is native views and native APIs.
The platform-view problem#
This is the section most comparison articles skip, and it’s the one that ends in migrations.
A platform view is any embedded native View — a WebView, a map, a camera preview, a video player, an AR session. Every cross-platform framework has to bridge these, and the bridge is where the failure modes live.
In Flutter, platform views require GPU context synchronization between the Impeller/Skia render thread and the platform view hierarchy. On well-behaved GPU drivers that handshake is fast and invisible. On certain Mali and PowerVR driver versions — common across the Samsung A-series, the Redmi Note line, and the entry-level MediaTek and Snapdragon SoCs that dominate emerging markets — the render thread holds a lock, the platform thread waits on the GPU, and at five seconds the system fires an ANR. Texture Layer Hybrid Composition reduces the frequency; it does not eliminate it across the device matrix.
I have the Play Console vitals to prove it. The full engineering breakdown — the stack signatures, the device matrix, the mitigations that worked and the ones that didn’t — is in our analysis of real-world Flutter platform-view ANRs on Mali and PowerVR GPUs. If your product’s core flow is a video-heavy WebView, a map, or anything that puts a native view under sustained load on low-end hardware, read that before you commit to Flutter.
In React Native, native views are first-class — a MapView or WebView is just a view in the tree, no render-thread handshake. That’s why the Kahf Kids migration removed the ANR surface by leaving Flutter: the parental-control video layer that was hanging on Mali simply stopped hanging once it was a native bridge, not a platform view.
Low-end device performance#
Most of my users are on cheap phones. That’s not a complaint — it’s the dominant reality for any product shipping to South Asia, Southeast Asia, Latin America, or Africa, and increasingly for budget-tier users in mature markets. The device matrix looks like this: MediaTek Helio or entry-level Snapdragon SoCs, Mali-G52/G57 or PowerVR GE8320 GPUs, 2–3 GB of RAM, often on 3G/4G with intermittent connectivity. That hardware mix shapes every architectural decision.
Flutter on low-end hardware is a paradox. For pure-Flutter UI — screens built from Material or Cupertino widgets, no native views in the path — it’s excellent. Impeller is tuned for these GPUs, and you’ll hit smooth frame rates where a comparable RN app is still warming up. The moment you put a platform view on screen, the paradox inverts, and the same cheap GPU that ran your Flutter list buttery-smooth stalls on the WebView next to it. I’ve watched it happen on a Redmi Note 11 in production.
React Native on the same hardware has historically paid a JS-bridge tax. The new architecture (Hermes + Fabric + JSI) substantially closes that gap — Hermes precompiles JS to bytecode and TurboModules skip the serialization overhead — but you’re still running a JS runtime alongside the native view system. For apps heavy on lists, animations, and gesture handlers, RN in 2026 is competitive with Flutter in a way it simply wasn’t in 2020. For apps heavy on raw computation, Flutter’s AOT Dart still wins.
Expo inherits RN’s perf profile. What Expo adds on low-end devices is operational: EAS Update lets you push JS fixes over the air without a store review, which is a real lever when your user base is on flaky networks and you need to ship a hotfix in hours, not weeks.
The honest rule: if your MVP is UI-heavy and stays inside Flutter’s canvas, Flutter will feel faster on a $90 phone. If your MVP is video-, map-, or camera-heavy on that same phone, RN/Expo removes a class of failures you cannot patch in Dart.
TV support#
This was the dealbreaker for Kahf Kids, and if TV is on your roadmap it might be yours.
Flutter’s TV story is weak. There’s no first-class Android TV or tvOS target. Focus handling, D-pad and remote navigation, and platform-view behavior on TV chipsets are all unreliable. You can make Flutter run on a TV; you cannot easily make it feel native to one. For a kids’ app where a meaningful chunk of engagement happens on the family living-room screen, that’s a structural miss — and it was one of the two reasons I stopped fighting.
React Native has a community-maintained react-native-tvos fork for Apple TV and reasonable Android TV support. Expo doesn’t add first-class TV support, but it doesn’t block it either — you can drop to prebuild and wire in the TV targets when you actually need them, without abandoning the rest of the Expo toolchain.
The full reasoning — including why this combined with the platform-view ANRs forced the call on Kahf Kids — is in why we migrated Kahf Kids off Flutter. Short version: if TV is a launch target, don’t pick Flutter. If TV is “maybe in year two,” Flutter is viable and you migrate later if you have to.
Developer experience, talent pool, time-to-MVP#
How fast can you ship a first version, and who can you hire to build it?
Flutter DX. Hot reload is still the best-in-class experience across all three options. Strong typing in Dart, a single language for UI and logic, and the Flutter DevTools performance overlay are genuinely pleasant to work in. The Dart talent pool is smaller than JavaScript’s, but developers cross-train fast. Time-to-MVP for a conventional app: excellent — I shipped the Crewlix HR platform on exactly this logic, because HRM software is business-logic-heavy and UI-repetitive, which is the shape where Flutter pays off fastest.
React Native DX. Fast Refresh is good, the JavaScript ecosystem is enormous, and you hire from a much larger talent pool. The cost is complexity in the native layers — Gradle and Xcode knowledge still matters, and the new-architecture migration is non-trivial on existing apps. Time-to-MVP for an app reusing mature native modules: very fast.
Expo DX. This is where Expo earns its keep. npx create-expo-app, expo prebuild, EAS Build producing signed iOS and Android artifacts without you opening Xcode, and EAS Update for OTA JS pushes. For a founder shipping their first app, Expo is the fastest path from laptop to TestFlight I know of. I delivered the Kahf Kids RN/Expo rebuild in three months with an AI-assisted workflow, and the Expo toolchain was a meaningful part of how that timeline compressed.
The talent reality in 2026: JavaScript developers outnumber Dart developers by roughly an order of magnitude. If hiring speed matters to you, RN/Expo has the deeper bench. If you want one tight team owning one codebase with strong typing and the strongest hot-reload in the business, Flutter has the edge.
Decision framework#
Here’s my opinionated guide. I’m an architect, not a diplomat — these are real recommendations, not “it depends.”
Choose Flutter when:
- Your UI is conventional: forms, lists, detail screens, dashboards, calendars.
- You want pixel-identical iOS/Android rendering without per-platform UI work.
- Your team is small and you want one language (Dart) for UI and logic.
- You’re not heavily dependent on WebView, maps, camera, or AR under sustained load.
- TV is not a near-term target.
This is why I picked Flutter for Crewlix and have kept it for the NCC App for seven straight years — 70+ modules whose core flows live in Flutter’s canvas. Right tool, right product.
Choose React Native (bare) when:
- You have an existing RN codebase, a JS-heavy team, and native modules you already maintain.
- You need fine-grained control over the native projects that prebuild would fight you on.
- You’re embedding into a brownfield app where RN’s partial-screen story is better.
Choose Expo when:
- You’re starting a new cross-platform MVP and want the fastest path to TestFlight and Play Internal.
- Your product stresses native views (video, maps, camera) on low-end hardware.
- TV is on the roadmap.
- You want OTA updates, cloud builds, and a config-plugin ecosystem instead of hand-patching native projects.
This is why I migrated Kahf Kids to RN/Expo. Right tool, right product — different product.
If you want the single sentence: Flutter for conventional UI and render consistency; Expo for everything that stresses native views, low-end hardware, or TV. Bare RN sits in between, for the cases where Expo’s prebuild gets in your way.
Migration reality#
Can you move if you pick wrong? Yes — but it isn’t free, and it isn’t “just rewriting the UI.”
A Flutter → RN/Expo migration is a full rewrite of the view and state layers; only your backend, your APIs, and your product spec carry over. I’ve done it: the Kahf Kids migration was three months of focused, AI-assisted work, and the engineering reasoning is documented in why we migrated Kahf Kids off Flutter. The platform-view ANRs went away; the parental-control contract held; the device matrix that was failing started passing.
The reverse — RN/Expo → Flutter — is the same shape: a view-layer rewrite. The deciding factor isn’t the direction; it’s whether the architectural fit is broken. If your core flow is hanging on Mali GPUs, no amount of Dart refactor will fix that — you migrate. If your team is shipping happily and the product fits the canvas, don’t migrate on a fashion impulse.
The lever most founders miss: a paid architecture audit before you commit. A few hours of senior time, mapping the product against the platform contracts, will tell you which way the decision actually lands before you’ve written a line of production code. It’s the cheapest money you’ll spend on the project, and I start most engagements exactly that way.
Conclusion#
All three of these stacks ship real apps to real users in 2026. The mistake isn’t picking the “wrong” one — it’s picking without knowing your product’s core flow, your device matrix, and your roadmap. Flutter is excellent for a large class of apps and I’ll keep recommending it. Expo-on-RN is excellent for a different large class, and on low-end hardware with platform views in the loop, it removes failures Flutter can’t.
If you’re staring at the choice and want a senior architect to map it against your actual product — the core flow, the device matrix, the stores, the timeline — that’s exactly what I do. Start a conversation.