This question arrives in nearly every mobile conversation, usually framed as a religious one. It is not. It is an economics question with a small number of genuine technical exceptions, and it can be answered in about ten minutes if you ask the right things.
The default is Flutter, and the reason is arithmetic
Two native applications mean two codebases, two sets of bugs, two release cycles, and — the part people underestimate — two teams who need to stay in sync on product decisions forever. Every feature is specified twice, built twice, tested twice and regressed twice.
Flutter collapses that into one codebase producing both platforms, with rendering that is genuinely fast because it draws its own widgets rather than bridging to platform ones. For a small or mid-sized team, that difference is not a nice-to-have. It frequently decides whether the iOS version ships at all, or whether it stays permanently six months behind Android.
There is a second-order benefit that matters more over time: design consistency stops being a coordination problem. When both platforms render from the same widget tree, a design system is enforced by the compiler rather than by review discipline.
The test we actually apply
We ask one question: is a platform-specific capability the core of the product, or a feature of it?
If your product is fundamentally about ARKit spatial mapping, low-latency audio processing, deep Apple Watch integration, live activities, or complex home-screen widgets — that capability is the product, and you should go native. Flutter can reach all of those through platform channels, but if you are writing substantial native code on both sides anyway, you have paid the cost of native without the benefit.
If those things are features — you need the camera, GPS, notifications, biometrics, background sync, payments, file access, Bluetooth — then Flutter handles them through mature plugins and the arithmetic wins comfortably.
What Flutter is honestly worse at
A recommendation you cannot argue against is not a recommendation, it is marketing. So here is the list.
- App size. A trivial Flutter app is larger than a trivial native one because it ships its own rendering engine. It matters at the low end of the market and it stops mattering once your app has real content.
- Brand-new OS features. When Apple or Google ships something at a keynote, native gets it that day and Flutter gets it when the plugin ecosystem catches up.
- Platform-idiomatic feel at the margins. Cupertino widgets are close but not identical to UIKit, and users who look closely can occasionally tell.
- Very heavy native interop. If half your app is platform channels, Flutter is adding a layer rather than removing one.
- Hiring in some markets. There are more native developers than Flutter developers in absolute terms, though the gap has narrowed considerably.
What about React Native, or a web wrapper?
React Native is a reasonable choice, particularly if your web team is already deep in React and you value sharing people rather than sharing code. We prefer Flutter for rendering consistency and for the fact that Dart's type system and tooling make large codebases easier to keep coherent, but a team with strong React expertise will ship faster in React Native than in a language they are learning.
A web wrapper — a website in a native shell — is almost always a false economy for a consumer product. It cannot work offline in any meaningful way, it feels wrong in ways users notice without being able to name, and it will struggle in store review if it offers nothing beyond the website. For an internal tool with a captive audience, it can be exactly right.
The decision in one paragraph
Choose Flutter unless a platform-specific capability is the reason your product exists. Choose native when it is, or when you already have two strong native teams and no coordination problem to solve. Choose React Native when your organisation's centre of gravity is React and that matters more than anything above. And be suspicious of anyone who answers this question the same way every time without asking what you are building.