Flutter or native: the decision, without the tribalism

Every few months someone publishes a benchmark showing Flutter renders a list marginally slower than SwiftUI, and the argument restarts. For almost every business app being commissioned this year, that benchmark is irrelevant to the decision.

The commercial choice comes down to four questions. Answer them honestly and the decision usually makes itself.

Question one: does the app need capabilities Flutter cannot reach?

This is the only technical question that genuinely settles the matter, and the honest answer is that the list is short and getting shorter.

Choose native when the product depends on:

• Advanced camera control — manual exposure, RAW capture, multi-lens switching, real-time video processing
• ARKit or ARCore as a core feature rather than a novelty
• Complex background processing — continuous location tracking with aggressive battery constraints, background audio, health data streams
• Deep OS integration — widgets with rich interaction, Siri or Google Assistant intents, CarPlay or Android Auto, watch apps
• Bluetooth Low Energy with unusual peripheral behaviour, especially medical or industrial hardware

Everything else — commerce, booking, banking front ends, logistics, field service, content, social, internal tools — Flutter handles without a user ever noticing.

Question two: what will maintenance cost over three years?

This is the question that decides most projects, and it is the one initial quotes obscure.

With two native codebases, every feature is specified once and built twice. Every defect is fixed twice, sometimes differently. Every OS update needs two rounds of testing. Two developers must be kept, or one developer context-switches and is slower at both.

Across a three-year life, the difference is not the 30 to 40 percent that shows up in the initial build. It compounds. The clients we see with two native codebases and a small budget end up with one platform quietly falling behind — usually Android, usually to the annoyance of the majority of their users.

Question three: how much does the interface need to be yours?

This one cuts both ways, and it is where the argument gets interesting.

Flutter draws its own interface. That means a distinctive design system renders identically on both platforms, and you get exactly what the designer drew. If your brand expression is central — a fitness product, a media app, anything with a strong visual identity — that control is valuable.

Native inherits platform conventions automatically, including accessibility behaviour, text sizing, keyboard handling and the small interaction details users expect without articulating. If your goal is for the app to feel unmistakably like an iPhone app, native gives you that for free, and Flutter requires deliberate effort to approximate.

Our practice is to use Flutter with platform-adaptive navigation and gestures, so the app follows platform conventions where users notice and uses our design system where it distinguishes the product. That is a middle path and it works well, but it is work rather than something you get automatically.

Question four: who maintains this in two years?

If you have or plan an in-house team, hire for what you can actually recruit. In Kerala and most of India, Flutter developers are plentiful and reasonably priced. Strong native iOS engineers are scarcer and cost more. In some Western markets the balance is different.

If the app will be handed to a client's internal team, one Flutter codebase is far easier to hand over than two native ones.

What about React Native?

React Native remains a good answer in one specific situation: you already have a React web application and a React team. Then the shared skills, shared logic and shared types are a real advantage, and over-the-air updates let you fix things without a store review.

If you are starting fresh with no React investment, we recommend Flutter. Its rendering consistency and animation performance are better, and the tooling is more coherent out of the box.

The costs nobody mentions

Flutter: app binaries are larger — typically 15 to 25 MB more than an equivalent native app. This matters in markets where users on entry-level devices with limited storage make deliberate uninstall decisions. Also, a new iOS feature is available to Flutter only after the plugin ecosystem catches up, which can be weeks or months.

Native: two release cycles, two sets of store metadata, two crash dashboards to watch, and the constant small drift between platforms that leads to features on one and not the other.

How we actually decide

In a discovery workshop we ask exactly the four questions above, and the outcome is usually clear within an hour.

Roughly 80 percent of the apps we build are Flutter. The remaining 20 percent are native, and almost every one of those has a specific hardware or OS integration requirement that made the decision for us.

If a development company recommends native for a standard business app without pointing to a specific capability requirement, ask what that capability is. If the answer is about performance in general terms rather than a named feature, be sceptical. On modern hardware, for the kind of app most businesses need, that difference is not something your users can perceive — but the maintenance bill is something you will feel every month.