QUICK ANSWER
React Native or Flutter: which should you choose?
Both ship real apps to both stores. Flutter draws every pixel with its own engine, so the design is identical everywhere. React Native uses the platform’s own views and is written in JavaScript or TypeScript, so it shares a language with a web frontend. Pick Flutter for pixel control, React Native for reuse, native for deep platform work.
This argument has been running for years and most of it is noise. The two frameworks are both mature, both ship apps that millions of people use, and both get you to the App Store and Google Play from one codebase. Anyone telling you one of them is simply better is selling something.
The choice comes down to two real differences and one question about your team. Flutter draws its own interface with its own engine. React Native uses the interface pieces the phone already has, and is written in the same language as most web frontends. The team question is who keeps the app alive after launch.
We ship React Native, and that is a bias worth stating up front rather than burying. What follows is what the two projects say about themselves, criterion by criterion, with the sources dated so you can check them.
How this comparison was built
Framework comparisons rot fast and most of them are written from memory. This one has a method, and the method is deliberately dull.
Read what each project says about itself
Every finding comes from first-party documentation, not from a blog post about a blog post. Where a project describes its own design in plain terms, that description is used rather than paraphrased into something sharper.
Sources: [rn-native-components], [flutter-faq]
Compare on differences a buyer can act on
Internal architecture is interesting and rarely decides anything. The criteria below were chosen because each one changes what you do next: which language you hire for, whether the design can be identical, whether you need a Mac.
Sources: [rn-new-architecture], [flutter-architecture]
Keep the framework question separate from the store question
Most of what makes shipping a mobile app painful is the app stores, and that part is identical whichever framework you pick. It is split out into its own criterion so it does not get counted against one side.
Sources: [apple-review-guidelines], [expo-submit-ios]
State our own bias where it applies
Playcode builds mobile apps with React Native and Expo. Every place that choice shapes a finding is marked, and Flutter wins the criteria it genuinely wins. A comparison that never concedes anything is an advertisement.
Sources: [expo-eas-build], [rn-typescript]
What this guide covers, and what it does not
The scope is the framework decision for a product team that has to pick one and get on with it.
Included
- React Native, Flutter, and writing separate native apps in Swift and Kotlin
- The language you write in and what a web team can reuse
- How each one puts an interface on the screen, and what that costs
- Getting an iOS build when nobody on the team owns a Mac
- What the app stores require regardless of your choice
Not included
- Performance benchmarks. None were run, so none are quoted
- Market share, hiring-market size, and job-board counts, which are opinions dressed as data
- Kotlin Multiplatform, .NET MAUI, and web-view wrappers, which are a different question
- The cost of building an app, which has its own guide
The eight things that actually decide it
Each criterion is here because it changes a decision. If a difference would not change what you do on Monday, it is not on the list.
The language, and what you can reuse
If your product already has a website, using the same language across both means one set of people, one set of types, and one mental model instead of two.
How the interface reaches the screen
This is the fundamental difference between the two, and every other UI difference follows from it.
Looking like the platform, or looking like itself
A brand-consistent app and a platform-native app are different products. You have to know which one you are ordering.
How far one codebase goes
Phones may not be the end of it. Web and desktop from the same source is worth real money to some teams and nothing to others.
Reaching the camera, sensors and native libraries
Every cross-platform framework hits a wall somewhere. What matters is where the wall is and how you get through it.
Getting an iOS build from the computer you own
For a solo founder on Windows this is not a detail, it is the entire feasibility question.
What the app stores demand either way
People blame the framework for costs the store imposes. Separating them stops you choosing badly for the wrong reason.
Who keeps it alive after launch
The framework you can staff beats the framework that scored better on paper, every time.
The three options, on every criterion
Two of these are the search you typed. The third is here because "should we just build it natively" is the same decision, and leaving it out would make the comparison easier than the choice really is.
React Native with Expo
Best for: Teams that already write JavaScript or TypeScript on the web, and anyone who needs an iOS build without owning a Mac.
You describe the interface with React components in JavaScript or TypeScript, and at runtime the framework creates the real Android and iOS views behind them. Expo adds the parts around it: a cloud build service, store submission and a phone preview.
| Criterion | Finding |
|---|---|
| The language, and what you can reuse | JavaScript, and TypeScript by default: React Native documents that new projects target TypeScript out of the box, and that you describe the interface with React components. If your website is already React and TypeScript, the language, the types and the way you think about state all carry across. On Playcode that goes one step further, because the mobile app, the web app and the backend sit in the same project and share the same accounts and database. Sources: [rn-typescript], [rn-native-components] |
| How the interface reaches the screen | React Native creates the corresponding Android and iOS views for your components at runtime. Its documentation states that because the components are backed by the same views as Android and iOS, the apps look, feel and perform like other apps. The redesigned internals, which Meta says have been proven at scale in its own production apps, added synchronous layout so a measured element no longer visibly jumps into place. Sources: [rn-native-components], [rn-new-architecture] |
| Looking like the platform, or looking like itself | You get the platform behaviour for free, including the small things nobody budgets for: the way a scroll bounces, how a text field behaves under a password manager, how a control reads to a screen reader. The cost is the mirror image of Flutter advantage. The same code can render differently on the two platforms, which is correct behaviour if you wanted a native feel and a defect if you wanted one design. Sources: [rn-native-components] |
| How far one codebase goes | The documented target is Android and iOS from one codebase. Community projects extend React Native to web and desktop, but the framework’s own documentation describes it as a framework for building Android and iOS applications, so treat anything beyond the two phone platforms as a separate investigation rather than an included feature. Sources: [rn-native-components] |
| Reaching the camera, sensors and native libraries | You use JavaScript to reach the platform APIs, and the framework ships a set of ready-made components for the common cases. Beyond that you use a community library, and React Native maintains a directory of them. The practical rule: a library containing native code needs a full build to test, so decide whether you need it before your first release rather than during it. Sources: [rn-native-components], [expo-eas-build] |
| Getting an iOS build from the computer you own | This is the clearest win on the board. EAS Build is a hosted service that produces installable iOS and Android binaries and can manage the signing credentials for you, and the submit step is documented as running on macOS, Linux and Windows. A founder on a Windows laptop can produce a real iOS app and upload it. Sources: [expo-eas-build], [expo-submit-ios] |
| What the app stores demand either way | Identical to every other option. You need your own paid Apple and Google developer accounts, and Apple guideline 4.2.6 requires an app made with an app generation service to be submitted by the owner of the content, which means you press submit. The framework changes nothing here. Sources: [apple-review-guidelines] |
| Who keeps it alive after launch | Anyone who writes React or TypeScript can read this codebase, which usually means the person who already maintains your website. That is the single most under-rated advantage: the app does not become a thing only one contractor understands. Sources: [rn-typescript] |
Tradeoffs
- The interface is assembled from the platform’s own components, so making a screen pixel-identical on iOS and Android takes deliberate work.
- A library that carries its own native code cannot load in a quick phone preview and needs a full build before you can test it.
- You inherit the quirks of two platforms rather than the quirks of one engine.
Flutter
Best for: Products where the design is the product and must be identical everywhere, and teams that want phones, web and desktop from one source.
You write in Dart, and Flutter draws every control itself with its own rendering engine instead of using the ones that ship with the device. That is why a Flutter app looks the same on every phone, and why it can reach desktop and web from the same code.
| Criterion | Finding |
|---|---|
| The language, and what you can reuse | Dart, with the graphics framework and the virtual machine written in C and C++. Flutter documents choosing Dart because it supports both a fast development cycle with stateful hot reload and ahead-of-time compilation to efficient machine code, which is a genuinely good technical reason. The consequence for a web team is simple: it shares nothing with a JavaScript or TypeScript frontend, so you are adding a language, not reusing one. Sources: [flutter-faq] |
| How the interface reaches the screen | Flutter’s own FAQ puts it plainly: it does not rely on web browser technology nor on the set of widgets that ship with each device, and instead uses its own high-performance rendering engine to draw widgets. The engine is built with C, C++, Dart, Skia and Impeller, which is the default renderer on iOS. This is the real architectural difference between the two frameworks, and it is a legitimate strength. Sources: [flutter-faq], [flutter-architecture] |
| Looking like the platform, or looking like itself | Flutter has its own implementation of each control rather than deferring to the system, including pure Dart implementations of both the iOS and the Android switch, and it ships Material and Cupertino libraries for the two design languages. So a design renders identically everywhere, which is exactly right for a brand-led product. The cost is that platform behaviour is reproduced rather than inherited, and reproduction always lags the original a little. Sources: [flutter-architecture] |
| How far one codebase goes | The widest reach of the three. Flutter documents compiling and deploying to iOS, Android, web and desktop, with desktop support stable on Windows, macOS and Linux. If your roadmap genuinely includes a desktop app, this is a real advantage over React Native and it is not close. Sources: [flutter-faq] |
| Reaching the camera, sensors and native libraries | The framework itself is deliberately small, and higher-level capabilities arrive as packages, including platform plugins such as camera and webview. The pattern is the same as React Native: anything the framework does not cover comes from a plugin wrapping native code, and the quality of that plugin becomes your problem. Sources: [flutter-architecture] |
| Getting an iOS build from the computer you own | Flutter documents that you can develop on Linux, macOS, ChromeOS and Windows, which is about writing the app rather than producing a signed iOS binary. We found no first-party hosted iOS build service in Flutter’s own documentation on 2026-08-16, and we did not test third-party continuous integration providers, so record this as unverified rather than as a limitation. Teams generally reach for a CI service with macOS machines, or a Mac. Sources: [flutter-faq] |
| What the app stores demand either way | Identical. Paid Apple and Google developer accounts, the same review, the same guidelines, the same person pressing submit. Nothing about Flutter makes the store easier or harder. Sources: [apple-review-guidelines] |
| Who keeps it alive after launch | You need someone who writes Dart. That is a real and findable skill with good tooling behind it, but it is a separate hiring decision from your web team, and for a small company a second language is a second thing that can end up with exactly one person who understands it. Sources: [flutter-faq] |
Tradeoffs
- Dart is a second language for a team that already writes JavaScript or TypeScript on the web, so nothing carries over from the website.
- Drawing its own controls means a platform change in look or behaviour arrives when Flutter implements it, not when the phone updates.
- We found no first-party hosted iOS build service in Flutter’s own documentation, so the no-Mac path is something you assemble yourself.
Separate native apps in Swift and Kotlin
Best for: Apps whose core value is deep platform integration, and teams that can staff two mobile specialists.
Two codebases, two languages, two teams or one team switching context. Everything the platform can do is available immediately, and everything costs twice.
| Criterion | Finding |
|---|---|
| The language, and what you can reuse | Swift for Apple platforms and Kotlin for Android, which has been the Kotlin-first recommendation since 2019. Nothing is shared between the two apps, and nothing is shared with your website. For a company whose product is one idea, that is three separate implementations of the same screens. Sources: [kotlin-android], [apple-xcode] |
| How the interface reaches the screen | Straight into the platform toolkit with nothing in between: Xcode is Apple’s own toolset for developing, testing and distributing apps for its platforms, and Jetpack Compose is the recommended modern toolkit for building native Android interfaces in Kotlin. There is no framework layer to explain a problem away with. Sources: [apple-xcode], [kotlin-android] |
| Looking like the platform, or looking like itself | Perfect, by construction, because it is the platform. New system behaviour appears in your app when the phone updates rather than when a framework catches up. If a reviewer or a design-conscious audience will judge you on the details, this is the ceiling. Sources: [apple-xcode] |
| How far one codebase goes | One platform per codebase. Two stores means two apps, and web and desktop are two more projects again. This is the option you choose in spite of its reach, not because of it. Sources: [apple-xcode], [kotlin-android] |
| Reaching the camera, sensors and native libraries | Everything, the day it ships, with no plugin in between and no waiting for a maintainer. If the entire point of your app is a new sensor, a watch, a widget or a deep operating-system integration, this is the honest answer and the cross-platform frameworks are a detour. Sources: [apple-xcode] |
| Getting an iOS build from the computer you own | No. Xcode is Apple’s own toolset for its platforms and it runs on the Mac, so native iOS development means owning or renting one. If your constraint is that you have a Windows laptop and a budget of zero, this option is closed before the comparison starts. Sources: [apple-xcode] |
| What the app stores demand either way | Identical again. The same paid accounts, the same review, the same guidelines. Building natively buys you no leniency from either store. Sources: [apple-review-guidelines] |
| Who keeps it alive after launch | Two specialists, or one who context-switches and is slower at both. It is the most durable choice technically and the most fragile one organisationally for a small team, because losing one person can leave half your product unmaintainable. Sources: [kotlin-android], [apple-xcode] |
Tradeoffs
- Every feature is built twice, and the two versions drift apart the moment one ships before the other.
- iOS development needs a Mac, so the no-Mac question has no answer here.
- It is the most expensive option to staff, and the hardest to restart if the specialist leaves.
Six rules that settle it
Find the first one that describes you and stop reading. If two apply, the earlier one wins.
The core feature is a deep platform capability: a sensor, a watch, a widget, background work the operating system controls
Choose: Build natively, and accept two codebases. A cross-platform framework will spend your first year fighting the one thing your product is for.
Tradeoff: Highest cost to build and to staff, and a second team before you have proven anyone wants the app.
The design is the product and it must be identical on every device, including desktop
Choose: Choose Flutter. Drawing its own controls is exactly the property you want, and it is the only one of the three with stable desktop support in its own documentation.
Tradeoff: Dart is a second language your web team does not have, and the no-Mac build path is something you assemble rather than something you are handed.
Your product already has a web frontend in JavaScript or TypeScript
Choose: Choose React Native. The language, the types and the people transfer, and on Playcode the app shares a backend and a database with the website so an account works in both.
Tradeoff: You accept small rendering differences between iOS and Android as the price of platform-native behaviour.
Nobody on the team owns a Mac and buying one is not in the budget
Choose: Choose React Native with a cloud build. It is the only one of the three whose own documentation says the build and the store upload run on Windows and Linux.
Tradeoff: You depend on a build service and a queue, and any library with unusual native code needs checking before you commit to it.
You do not yet know whether anyone wants this product
Choose: Ship the web version first and put it in front of real users. A responsive web app needs no developer account, no review and no store listing, and it answers the only question that matters at this stage.
Tradeoff: No icon on the Home Screen and no store search, which for some audiences is the credibility you needed.
You are not technical and this debate is not a good use of your time
Choose: Pick a tool that has already made the choice. Playcode builds mobile apps with React Native and Expo, in the same project as the web app and the backend, so the framework question never reaches your desk.
Tradeoff: You are taking somebody else’s decision. It is a defensible one, and this page shows the reasoning, but it is still not yours.
Skip the debate
Describe the app. The framework decision is already made.
Playcode builds mobile apps with React Native and Expo, in the same project as your web app and backend, so one description gets you both.
Start BuildingNo credit card required.
See what Playcode buildsThe capability reference for the app-building side of the product.
What this guide does not know
The value of a comparison is in what it admits. Here is the boundary of ours.
- No benchmark was run. Every performance claim you read anywhere, including ours, is one app on one device doing one thing, and yours is a different app.
- We found no first-party hosted iOS build service in Flutter’s own documentation on 2026-08-16, and we did not test third-party continuous integration providers. That is an unverified gap, not a proven limitation.
- Hiring-market claims are left out on purpose. Job-board counts are easy to quote and easy to be wrong about, and they vary enormously by city.
- Both frameworks release frequently and both were read on one day. The review date on this page is the honest shelf life.
- Playcode ships React Native and Expo, which is a bias. It is stated in the lead, in the methodology and again here rather than hidden in a footer.
Sources
First-party documentation only, each read on 2026-08-16. Where a project describes its own design, its own words are used.
[rn-native-components] React Native:Core Components and Native Components
Checked August 16, 2026. Supports: React Native creates the corresponding Android and iOS views at runtime, and is described as a framework for building Android and iOS applications with React.
[rn-new-architecture] React Native:About the New Architecture
Checked August 16, 2026. Supports: The redesigned internals, proven at scale in Meta production apps, and the synchronous layout behaviour they enable.
[rn-typescript] React Native:Using TypeScript
Checked August 16, 2026. Supports: New React Native projects target TypeScript by default.
[flutter-faq] Flutter:Flutter FAQ
Checked August 16, 2026. Supports: Flutter uses its own rendering engine rather than the widgets that ship with each device, is written in Dart, supports development on Linux, macOS, ChromeOS and Windows, and deploys to iOS, Android, web and desktop.
[flutter-architecture] Flutter:Flutter architectural overview
Checked August 16, 2026. Supports: Flutter implements each UI control itself rather than deferring to the system, ships Material and Cupertino libraries, and delivers higher-level capabilities as packages.
[expo-eas-build] Expo:EAS Build
Checked August 16, 2026. Supports: A hosted service that builds installable iOS and Android binaries and can manage app signing credentials.
[expo-submit-ios] Expo:Submit to the Apple App Store with EAS Submit
Checked August 16, 2026. Supports: The submit step runs on macOS, Linux and Windows, and the release to production is started from App Store Connect.
[apple-review-guidelines] Apple:App Review Guidelines
Checked August 16, 2026. Supports: Guideline 4.2.6, which requires an app created with a commercialised app generation service to be submitted by the provider of the app content.
[apple-xcode] Apple:Xcode
Checked August 16, 2026. Supports: Xcode is Apple’s own toolset for developing, testing and distributing apps for Apple platforms.
[kotlin-android] JetBrains:Kotlin for Android
Checked August 16, 2026. Supports: Android development has been Kotlin-first since 2019, and Jetpack Compose is the recommended modern toolkit for native Android interfaces in Kotlin.
Questions people ask about React Native and Flutter
Is Flutter faster than React Native?
We did not measure it and we are not going to claim it either way. The architectures differ in how the interface is drawn, and that produces different results for different kinds of app. Any published number is one app on one device. For most business apps the bottleneck is your network and your database, not the framework.
Why does Playcode use React Native rather than Flutter?
One language across the whole project. The web app, the backend and the mobile app are all JavaScript and TypeScript in one place, sharing accounts and a database, so a change to the data model is one change. Flutter would mean Dart on the phone and TypeScript everywhere else. That is a reasonable trade for some teams and the wrong one for ours.
What about React Native vs native?
Native wins on depth and loses on cost. React Native creates the same platform views underneath, so ordinary screens look and behave natively already. Go native when the core feature is a platform capability, a watch, a widget or heavy background work. Do not go native to win an argument about performance you have not measured.
Can I switch frameworks later?
The interface layer is a rewrite, not a migration. What survives is your backend, your database and your business rules, which is a reason to keep those on a server rather than inside the app. Choose so that a switch would be unfortunate rather than fatal.
Do I need a Mac for either of them?
Not for React Native with Expo: the build service produces the iOS app and the submit step is documented as running on Windows and Linux too. For Flutter you can develop on Windows, but we found no first-party hosted iOS build service in its documentation, so that path is one you put together yourself.
Which one is easier to hire for?
We left market-size claims out because they are easy to quote and easy to get wrong. What we can say from the documentation is what you would be hiring for: JavaScript or TypeScript for React Native, Dart for Flutter, Swift and Kotlin for native. If you already employ web developers, one of those lists is already on your payroll.
Does the choice change anything about publishing to the App Store?
No. You need your own paid Apple and Google developer accounts whichever you pick, the review is the same, and Apple guideline 4.2.6 means the owner of the content presses submit. Nobody publishes on your behalf, and any tool that says otherwise is describing something Apple does not allow.
Build it on Playcode
One project. Web, backend and a mobile app.
One language across all three, one database behind them, and an iOS build that runs in the cloud rather than on a Mac you would have to buy.
Start BuildingNo credit card required.