Most companies asking for an app do not need a debate about frameworks. They need one app on two platforms, shipped once, maintained by a team they can actually hire. Flutter and React Native both do that. The choice between them is decided by your situation, not by benchmarks, and it is usually clear after six questions.
This is how we work through them at the start of a mobile engagement. The answers go into the discovery scope document, next to the architecture note, so the reasoning is on record when someone asks two years later.
Question 1: who maintains the app after launch
This is the question that matters most and gets asked least. An app lives for years. The team that owns it in year two is rarely the team that built it in year one.
If your in-house engineers write React for the web, React Native is the natural fit. The component model, the state libraries and most of the tooling carry over, and a web engineer can review a mobile pull request without learning a new language. If your team has no JavaScript background, or you will rely on an outside team for the life of the app, that advantage disappears and Flutter is at least as easy to staff.
Question 2: how much of the design is custom
React Native renders real platform widgets. A button is an iOS button on iOS and an Android button on Android, which is what most users expect from a form-heavy business app. Flutter draws every pixel itself, so a heavily branded interface with custom controls, animations and charts looks identical on both platforms and costs less to keep consistent.
The rule we apply: standard controls and platform conventions favour React Native; a design system of your own, or an app where the interface is the product, favours Flutter.
Question 3: how deep the app goes into the device
Camera, background location, Bluetooth peripherals, payments, biometrics and push notifications all work in both frameworks through packages. The difference shows at the edges: a new platform feature, an unusual hardware integration or a vendor SDK that ships only native libraries.
React Native's new architecture makes native modules cheaper to write than they were, and its community packages cover the common cases. Flutter's platform channels are straightforward, and its package ecosystem is large, but a vendor SDK with no Flutter wrapper means writing and maintaining one yourself. Before we recommend either, we list every integration the app needs and check each one for a maintained package. That list is a discovery deliverable, not an afterthought.
Question 4: performance where it is visible
Both frameworks are fast enough for the large majority of business apps: lists, forms, maps, media, chat. Where they differ is in specific workloads. Flutter's rendering pipeline is consistent for heavy animation and custom drawing. React Native has closed most of the historical gap with its new renderer, and it still benefits from the platform's own list and text components in content-heavy screens.
If performance is a real concern, we do not argue from articles. We build a spike during discovery: the one screen or interaction that worries you, in both frameworks if necessary, measured on a mid-range Android phone rather than the newest iPhone. That is usually a two-day task and it settles the question with evidence.
Question 5: web and desktop later
Flutter compiles to web and desktop from the same codebase. The web output suits internal tools and dashboards more than public marketing pages, which need server rendering for search. React Native reaches the web through separate projects that share logic more than interface.
If the roadmap includes a desktop app or a shared internal web tool, that weighs towards Flutter. If the web product already exists in React, sharing logic and components with React Native weighs the other way.
Question 6: the ecosystem you are committing to
Flutter is developed by Google; React Native by Meta, with Microsoft, Shopify and others contributing. Both have stable release cadences and long public roadmaps. Neither is going away. The practical check is narrower: are the ten packages your app depends on maintained, and does each have more than one maintainer? We run that check before the scope is signed, because an abandoned payment or map package is a cost you carry, not the framework's.
When the answer is native
Sometimes the honest answer is two native apps. The cases we see: an app whose core is a platform feature that the cross-platform layer wraps badly, such as advanced camera pipelines, audio processing or watch and widget extensions; an app that must adopt each new OS capability on the day it ships; and an app whose team is already native and productive. Cross-platform is a means to a cheaper, faster single codebase. When it stops being cheaper or faster, we say so.
What the decision costs later
Whatever you choose, plan for the framework upgrade cycle. Both Flutter and React Native publish major versions that touch build tooling, and a project left two years behind becomes an expensive upgrade.
Plan for the store side too. App Store and Google Play policies change every year, and a framework does not shield you from them; the next article in this series covers how to get through review without losing a week.
How we write the recommendation
The discovery document records, for the app in question: the maintaining team and their skills, the design fidelity needed, the integration list with a package status for each, the performance spike result if one was run, the roadmap beyond mobile, and the ecosystem check. Then one paragraph with the recommendation and the main thing that would change it. A client who reads that paragraph can disagree with it on evidence, which is the point.
If you are weighing the two frameworks for an app now, send the integration list and the design direction through the proposal form and we will tell you which way we would lean and why. What the build itself involves is on the mobile app development page.
