Flutter or native development?

Flutter promises the same thing as all cross-platform technology: one codebase for both iOS and Android instead of two. But Flutter keeps that promise its own way, with the Dart language and its own rendering engine that draws every pixel itself. Both choices have consequences a buyer should understand before the technology gets locked in.

Flutter’s own rendering engine – the strength and the price

Native apps, and React Native too, build the interface out of the platform’s own components. Flutter does the opposite: the framework draws the entire interface with its own engine, on top of a thin platform surface.

The strength is consistency. The app looks identical on an old Android phone and a new iPhone, the design system renders exactly as the designer intended, and animations flow smoothly. For brand-driven apps with their own visual language, that’s a genuine argument.

The price is platform feel. An iPhone user notices, often unconsciously, when scroll physics, transitions, and controls don’t behave exactly like the rest of the phone. Flutter can mimic the platforms’ behaviors, but that’s exactly what it is, a mimicry that has to be built and maintained, not something the app gets for free. The more it matters that the app feels like part of the operating system, the more this point weighs.

A practical side effect is release pace: with a shared codebase, the iOS and Android versions ship in sync, built by the same team against the same backlog. With two native tracks, active coordination is needed to keep the stores from drifting apart, work that rarely shows up in the quote but always shows up in the maintenance.

Dart and the talent question in the Swedish market

Native development happens in Kotlin and Swift, two languages that carry the entire Android and iOS ecosystems respectively and therefore a large, stable talent base in Sweden. Dart is in practice used almost only for Flutter.

For a single project, it matters little; an experienced agency or a contracted team gets the build done. The question is what happens in years two through ten. The app needs to be maintained, developed further, and sometimes change hands. That’s when the language choice becomes a staffing question: how quickly will you find a replacement when the Flutter developer leaves, and at what price? The pool of Dart developers is growing, but it’s still considerably smaller than for Kotlin, Swift, or JavaScript. That doesn’t make Flutter the wrong choice, but it makes the staffing plan a mandatory part of the decision, not a footnote. Concretely: ask the vendor to explain how maintenance will be staffed in year three, not just who builds it in year one, and budget for some price premium on scarce specialist skills if the app is to be run internally going forward.

When native is still worth two teams

There are situations where two native codebases justify their double cost:

• The app is your core product and needs to feel perfectly at home on every platform, down to every detail.
• Hardware-close core features – advanced Bluetooth, background services, AR, or specialized peripherals – where the platforms’ own APIs give the shortest path and the most stable operation.
• Extreme performance requirements such as real-time audio or heavy video processing.
• The organization already has established iOS and Android teams delivering well, in which case the switching cost is a project of its own.

Outside these situations, it’s hard to economically justify two parallel codebases: every feature gets built, tested, and maintained twice, year after year.

A concrete scenario

Picture an event app: schedule, tickets, maps, notifications. Built natively, it requires two development tracks, each implementing the same ten screens separately, perhaps SEK 1.2-1.8 million in total. With Flutter, the screens get built once, with shared logic and design, for a clearly lower total cost and simultaneous releases in both stores.

Now flip the scenario: an app whose core is controlling its own hardware over Bluetooth in the background, with a requirement for perfect platform integration. There, the native APIs can be half the product, and two teams a reasonable insurance premium.

Decision criteria in short

Weigh three things: how central platform feel is to your product, how hardware-close the core features are, and how you’ll staff the app over the next five years. Two out of three pointing toward Flutter argues for native; otherwise a shared codebase is usually the right starting point, in Flutter or in React Native, our main stack at Weapp. Not sure where your app lands? Get in touch and we’ll reason through your specific situation.