Every mobile project starts with the same question, usually asked in the first ten minutes of a discovery call: "Should this be native or cross-platform?" The honest answer is that for most business apps the question no longer matters as much as it did in 2020 — Flutter has closed most of the gap — but "most" is doing real work in that sentence. This post is the decision path we walk internally, including the cases where we still say no to Flutter.
Where Flutter wins by default
For the majority of the apps an agency like ours is asked to build — field-service tools, loyalty apps, B2B ordering, internal dashboards with a mobile face — Flutter is the default, and it is not close.
One codebase is a compounding discount
The saving is not the famous "write once, run twice". It is everything downstream: one CI pipeline, one test suite, one code review per feature, one place a bug can live. Over a two-year product life, the maintenance discount dwarfs the build discount.
The UI ceiling is higher than its reputation
Flutter's rendering model — it draws every pixel itself rather than borrowing platform widgets — used to be its liability. In practice it is why heavily branded, animation-rich interfaces are often easier in Flutter than in native toolkits. If your design language is your own rather than Apple's, drawing it once is a feature.
Where we still go native
Three situations reliably push us to Swift and Kotlin, and we tell clients so before they sign anything.
- Deep hardware work. Sustained Bluetooth sessions, background audio, camera pipelines with custom processing — the plugin layer can do all of these, but every platform quirk now lives behind an abstraction someone must maintain.
- Platform-first products. If the app should feel like an extension of iOS — widgets, App Intents, live activities, tight Watch integration — chasing that through a cross-platform layer costs more than writing it twice.
- An existing native team. If your in-house engineers will inherit the code and they are Swift people, handing them a Dart codebase is a disservice, whatever the benchmark charts say.
The stack question is really a staffing question in disguise: who maintains this in year two, and what do they already know?
The questions that actually decide it
Skip the benchmark blog posts. These are the questions that settle the choice in practice:
- Will this app's interface follow your brand or the platform's conventions?
- Is there any feature on the roadmap that touches hardware for more than a demo?
- Who owns the code eighteen months from now, and what language do they think in?
- Do the iOS and Android releases need to ship the same day, every time?
Two or more answers pointing at the platform, and we quote native. Otherwise Flutter — and we put that reasoning in the proposal, so the choice is auditable when someone asks in a year.
The cost conversation, honestly
A Flutter build is typically 30–40% cheaper than dual-native for the same scope, not the 50% the marketing decks claim — the discount erodes on the edges where platform-specific work sneaks back in. We would rather you hear that number in discovery than discover it in a change order.
If you are weighing a mobile build and want the reasoning applied to your actual feature list, talk to us — the stack recommendation is part of every discovery, not a paid add-on.