Flutter or native? What we actually recommend after years with both

Flutter or native is app development's question of faith — and we stand with one leg in each camp. Our Flutter apps run in both stores, our native apps on four Apple platforms. Here's the level-headed answer we also give clients in the first conversation.

Cards on the table first: in 2021 we built ClickTestBuy twice, natively — Swift for iOS, Kotlin for Android. RoadReview and LS-Athletics are Flutter, one codebase for both stores. MyMonty is native for iPhone, iPad, Mac and Apple Vision. Three projects, three different answers — and all three were right for their project. Which is exactly the thesis of this article: the question isn't which framework is better, but what fits the product, the team and the budget.

The question comes up in almost every first conversation about an app, usually in the form "We've heard Flutter is cheaper — is that true?". The honest answer is a decision tree, not a yes. And it starts with an observation that tends to get lost in framework debates: to users, the framework is invisible. Nobody deletes an app because it's written in Flutter — but they very much do because it starts slowly, stutters, or lacks the feature the other platform has had for ages. The framework choice is a means towards exactly those goals, not the other way round.

Where Flutter shines

The short version: business apps that have to ship on iOS and Android at the same time, and whose interface belongs to the app — not to the operating system. RoadReview is our best evidence: the app documents driving lessons — map, mistake tags, voice notes, driving progress — and runs for instructors and students on iOS and Android. The frontend is Flutter; behind it work NestJS and PostgreSQL, maps come from Google Maps, push via Firebase. Every feature is built once and ships in both stores on the same day.

• One team instead of two. The same developer, the same pull request, the same bugfix for both platforms. For a small studio like ours — and for our clients' budgets — that's the decisive difference.
• Feature parity is the normal state, not a project. With two native apps, one platform is always trailing; on ClickTestBuy we felt that daily.
• The ecosystem has grown up. Camera, maps, push, payments — for LS-Athletics even the HealthKit integration sits behind a well-maintained plugin. The days of building your own bridges for every native API are over.
• The bill. The frontend share is paid once instead of twice — often the largest single item in a business app.

And honestly: by default, Flutter apps look like Flutter, not like iOS or Android. For business apps with their own design language that's irrelevant to actively desirable — the app should look like the brand, identical on both platforms. Whoever wants pixel-perfect platform feel instead pays for it with extra effort that nibbles away at the one-codebase advantage.

Where native wins

• Deep platform features. Widgets, Live Activities, App Intents, Watch apps: doable with Flutter — but each of those is native code anyway, which then gets connected through bridges. Whoever lives off these is better off going native directly.
• Multiple Apple platforms. MyMonty, our digital handbook for water-damage restoration, runs on iPhone, iPad, Mac and Apple Vision — from one Swift codebase. Inside the Apple world, the "one codebase" argument flips around.
• Peak graphics and sensor performance. Real-time rendering, elaborate animations at 120 Hz, AR: here you don't want an abstraction layer between you and the system.
• Day one of a new OS. Native apps can adopt new system features on keynote day. The Flutter ecosystem needs weeks to months until the plugins catch up — usually irrelevant, sometimes decisive.

The MyMonty case is the most instructive: Android simply wasn't a requirement there. The target devices were the technicians' iPhones and iPads, plus Mac and Apple Vision for training. Flutter wouldn't have halved anything there — only added a layer.

A second point that's rarely said out loud: native is also a staffing question. Swift and Kotlin developers think in their platforms, know the conventions, the review pitfalls, the quirks of the devices. Whoever has a well-practised iOS team in-house gives away its strongest muscle with Flutter. Whoever — like most mid-sized companies — has no app team at all and commissions a partner, for them this argument doesn't count: then product and budget decide.

What about performance?

The most common worry in conversations, so it gets its own paragraph. For business apps, Flutter performance has been a non-issue for years: lists, forms, maps and animations run smoothly — RoadReview renders routes with markers in real time, and no driving instructor has ever asked about the framework. The honest limits lie elsewhere: very long lists with complex cells need to be built properly (that's just as true natively), cold start is a touch heavier than in a lean native app, and whoever genuinely pushes the limits of graphics performance will feel the abstraction layer. In short: performance is rarely the reason to decide — platform depth and team shape are.

The decision guide

Five questions, in this order. Usually the matter is settled after three:

1. Do you need iOS and Android? If not — Apple only, maybe even iPad and Mac on top — native is the shortest path.
2. Does the app live off platform features? Widgets, Watch, deep system integration as the core of the product (not as a nice-to-have): native.
3. Is the interface your own design language? Business app, own branding, identical on both platforms: Flutter.
4. What does the team look like? A small team that has to serve both stores is more honestly set up with one codebase than with two halves.
5. What about graphics? Games, AR, real-time visualization: native — or a proper engine right away.

What that means for budget and maintenance

For the budget the matter is clear: for a product on both platforms, Flutter saves the second frontend build — roughly a third of the total bill depending on the project, because backend, design and project management stay the same. Whoever needs only one platform saves nothing with Flutter. And for the negotiation with any provider: have the savings shown to you, not just promised. A quote saying "Flutter, therefore cheaper" without a broken-down backend and design share hasn't done the maths — it has just adopted the buzzword.

On maintenance, people like to cheat — in both directions. Flutter means: maintain one codebase, but ride along with the framework upgrades every year — and occasionally wait for a plugin. Native means: two codebases following their respective OS cycles — but never a middle layer between you and Apple or Google. After our years with both: for business apps, Flutter maintenance is clearly cheaper in total; for platform-deep apps it flips around.

Concretely, maintenance looks like this for us: once a year the big Flutter upgrade is due — one to two days if the dependencies have been kept tidy, considerably more if not. In between, small plugin updates that ride along with the regular store releases. For the native apps it's the annual OS cycle: new Xcode version, changed permissions, adjusted APIs. Neither path is maintenance-free — whoever tells you otherwise has never operated an app themselves for years.

Our default recommendation is therefore unspectacular: business app for both stores → Flutter. Apple-only or platform-deep → native. In the first conversation we answer the question honestly — even when the answer is "native". How we build and operate apps is on the app development page; RoadReview can be examined in detail in the showcase. And whoever already has a native app that works: don't rewrite it. A rewrite for framework reasons is almost never the best investment.