The Flutter question usually arrives dressed as a budget question. One team instead of two, one codebase instead of two, both app stores at the same time. That saving is real, and it is why cross-platform keeps winning the argument in rooms where money is being counted. The saving is also not free. The bill arrives in specific and predictable places.
What cross-platform actually buys you
One team. One codebase. Behaviour that matches on both platforms because it was written once. The third of those is the one teams underrate. Companies running separate iOS and Android apps lose a surprising share of every week to the gap between them: a bug that only exists on one side, a feature that shipped in March on Android and in May on iOS, a settings screen where two engineers ordered the toggles differently, a release that slips because one store review ran long. That drift is permanent, and it widens as the product grows.
The mechanism behind Flutter is worth understanding even if you never write a line of it. Flutter paints its own interface onto a canvas rather than handing off to UIKit and the Android view system. Everything on screen is drawn by Flutter. That single decision explains almost every strength it has and almost every limit it runs into.
Where Flutter is the stronger choice
Design-heavy interfaces
Because Flutter draws everything itself, a designer can specify something unusual and you can simply build it. Custom motion, brand-specific components, layouts that look nothing like a stock platform form. On native you would be fighting the platform widgets to get there. In Flutter there are no platform widgets to fight, which is either liberating or terrifying depending on the quality of your design work.
Internal and field tools
Warehouse scanners, inspection apps, driver tools, anything used by staff on a mixed fleet of devices. Nobody is holding these to the App Store's design language. What matters is that the app behaves identically on a five-year-old Android handset and the regional manager's new iPhone, and that two engineers can keep the whole thing maintained while also doing other work.
Reaching both platforms with a small team
If you have three mobile engineers and need to be on iOS and Android, the arithmetic is not close. Two native codebases with three engineers gives you two understaffed teams, each permanently behind and each blaming the other for the release date. One Flutter codebase with three engineers is a functioning team.
Predictable rendering across devices
Since Flutter controls every pixel, a screen looks the same everywhere it runs. For products with strict brand requirements, or regulated products where the exact presentation of a number or a warning matters, that predictability has genuine value. It also makes visual regression testing tractable, which is not true of native apps spread across dozens of device configurations.
Where native remains the better answer
Deep OS integration
Home screen widgets, share sheets that do something clever, live activities, watch complications, custom keyboards, real hooks into system services. All of it is reachable from Flutter through platform channels. All of it also means writing the native code anyway and then maintaining a bridge on top of it. If your roadmap is mostly this kind of work, you end up running a native project with extra steps and a Dart layer nobody enjoys.
Heavy background work
Continuous location tracking, long uploads, audio that keeps playing, sync that has to happen while the app is closed. Background execution is where iOS and Android differ most sharply, both are aggressive about killing work they did not authorise, and no abstraction smooths that over. You will be reading Apple's and Google's background execution rules line by line regardless of what you built the UI in.
Platform features on release day
If your product needs the capability announced at WWDC to be live in your app the week it ships, write native. Plugin ecosystems do catch up, and catching up is measured in months. For most companies that delay is irrelevant. For a company whose pitch depends on being first to a new platform capability, it is the whole business.
Tight hardware and sensor work
Camera pipelines, Bluetooth peripherals, real-time signal processing, medical devices shipping a certified SDK. Hardware vendors publish native SDKs and support them. The Dart bindings are usually community-maintained and usually a version or two behind. If your product is fundamentally a piece of hardware with an app attached, the app should be native.
The middle ground most teams should take
Ship Flutter first. Take one platform native later, if and only if it earns the cost.
This works because the expensive part of a mobile product is rarely the interface code. It is working out what the product should do. A year of running a Flutter app teaches you which screens people actually open, which flows carry revenue, and exactly where the platform limits bite. If iOS turns out to carry most of the revenue and you need three capabilities Flutter cannot reach cleanly, rewriting that one app becomes a well-understood job with a specification you now genuinely have.
The rewrite only makes sense once the product has stopped changing shape. Rewriting a moving target is how a team ends up maintaining two unfinished apps and shipping neither.
The failure mode here is the team that promises itself a native rewrite from day one and treats the Flutter build as a placeholder. Placeholders get shipped, then neglected, then underfunded. Either commit to Flutter as the real product or write native now.
Two questions to settle before committing
Does anyone on the team know Dart?
The language itself is unremarkable and a competent engineer is writing useful code inside a fortnight. Flutter is the longer curve: state management, the widget lifecycle, rendering performance, and keeping a large widget tree readable. Budget a month before anyone is properly productive, and assume the first few screens get rewritten once someone understands the framework properly.
What does hiring look like where you are?
Some markets have a deep Flutter pool and charge a serious premium for experienced iOS engineers. Others run entirely the other way. Look at live listings and speak to actual candidates before the architecture meeting, because this varies enormously by city and it overrides most of the reasoning above.
Flutter is a sound default for mobile products built by small teams, and a poor choice for products whose value sits close to the operating system or the hardware. Work out which one you are before anyone writes code. The question has a clear answer, and it is usually obvious within a minute of somebody asking it out loud.