Most Flutter-versus-native arguments are people describing different apps. Someone building a camera-heavy product and someone building a field-service tool will reach opposite conclusions, and both will be right about their own project.
The useful version of the question is narrower: what does this specific app need that would make one choice wrong? Four things decide it. Everything else is preference.
1. How close to the hardware do you need to get
This is the one that actually rules Flutter out.
Flutter reaches the platform through plugins. For the common things — camera, location, notifications, biometrics, file storage, Bluetooth — mature plugins exist and work. For anything newer or more specialised, you are either writing the platform channel yourself or waiting.
The practical test: list every device capability your app touches, then check whether a maintained plugin exists for each. If two or more are missing, you are writing native code inside a Flutter app, which is the worst of both.
Native wins outright for AR, heavy real-time video processing, deep integration with platform-specific frameworks, and anything needing a new OS capability on day one.
2. Whether the interface must feel native, or must feel like your brand
Flutter draws its own widgets. It does not use the platform’s UI components, it renders pixel-for-pixel what you designed on both platforms.
That is an advantage when the product has its own visual identity and you want it identical everywhere. It is a disadvantage when the app should feel like it belongs to the operating system — where users expect iOS conventions on iOS.
Business tools, internal apps and branded consumer products usually want consistency. Utilities that sit alongside the system apps usually want native behaviour.
3. How much of the app is shared logic
The saving from cross-platform is not in the interface. It is in everything behind it — models, validation, API clients, offline sync, business rules.
An app that is mostly logic with a thin interface saves enormously. An app that is mostly bespoke interface with a thin API saves much less, because you rebuild the expensive part either way.
A rough test: if you sketch the app as screens versus rules, and the rules side is longer, cross-platform pays.
4. Who maintains it in two years
This is the factor teams weigh least and regret most.
Two native codebases mean every feature is built twice, tested twice, and can drift. For a small team that is not a cost multiplier of two — it is worse, because the platforms fall out of sync and the gap compounds.
One Flutter codebase means one developer can ship to both platforms. For a company without a dedicated iOS engineer and a dedicated Android engineer, this frequently decides it on its own.
What we do in practice
We build most business applications in Flutter. The apps we have shipped — an Islamic companion app with offline prayer tracking, a dealer management tool for an ISP in Australia, the field application for a case management platform with GPS shift tracking — all fit the same profile: substantial shared logic, a designed interface rather than a platform-native one, and a team that cannot staff two native tracks.
We would reach for native if an app were built around the camera, needed a brand-new OS capability immediately, or had to feel like a system utility.
The decision in one paragraph
If your app is mostly business logic, has its own visual identity, uses only common device capabilities, and will be maintained by a small team — build it in Flutter and do not spend another week debating it. If it lives on the camera, needs day-one support for new OS features, or must feel indistinguishable from the system apps — build it native and accept the cost of two codebases.
The expensive mistake is not picking the wrong one. It is picking cross-platform for an app that needed native, discovering it six months in, and rewriting.
We build mobile applications in Flutter and native. If you are deciding, tell us what the app has to do and we will tell you honestly which way it points — start a conversation.