In 2020 I wrote about the question “Website or mobile app?”. Once you've decided you need an app, the next question comes: how do we build it? Separately for each platform, or with one codebase for both?
I work with Flutter myself, but in this post I won't recommend it for every project. Let's look at the differences.
What native is, and what Flutter is
Native means an app built with each platform's own language and tools: Swift for iOS, Kotlin for Android. You end up with two separate apps, two separate codebases and often two separate teams.
Flutter is Google's open-source toolkit. One codebase written in Dart produces both an iOS and an Android app. If you want, you can build web and desktop versions from the same code as well. It isn't the only tool in this space — there are alternatives like React Native — but the approach is the same: one codebase, several platforms.
Flutter's strengths
- One codebase, one team. A feature is written once and a bug is fixed once. That has a direct effect on both the budget and the timeline.
- The same look. The app looks and behaves the same on both platforms. That matters for a brand.
- Fast development. Seeing a change on screen instantly speeds up interface work a lot.
- Performance that's good enough. In most business apps — a store, orders, bookings, a personal account — users don't feel any difference.
Its limits
- App size is somewhat larger than a native app.
- New platform features sometimes arrive with a delay or require native code.
- Dependence on plugins. Some device features need a ready-made plugin; if the plugin is poorly maintained, the problem becomes yours.
- The platform's “feel”. iOS and Android users are used to different behaviours. You can do that in Flutter too, but it takes extra attention.
When native is better
- Heavy graphics, games, augmented reality.
- Deep device features: Bluetooth hardware, constant background work, health sensors.
- When only one platform is the target — then the “two platforms” advantage disappears.
- When the company already has separate iOS and Android teams.
Maybe you don't need an app?
For content, a catalogue, a simple form or bookings, a well-built mobile site or a PWA is often enough: nothing to install, no store review to wait for, and it shows up in search. I covered this in detail in “Is PWA the end of mobile apps?”. An app only makes sense when the user finds a reason to keep it on their phone.
6 questions to decide
- Which platform are your users on? If they're on both, Flutter is a strong candidate.
- Which device features do you need? If the list is long and specialised, look at native.
- Can the budget cover two separate teams?
- How soon do you need to launch? If speed matters, one codebase wins.
- Does the app need to work offline? It's possible either way, but it has to be planned in advance.
- Who will maintain it in two years? It should be easy to find developers for the technology you choose.
The bottom line
For most startup and business apps, Flutter is a smart start: one codebase, one team, two platforms. But “everyone uses it” isn't an argument. The argument is your users and your app's requirements.
I wrote about how small to keep the first version in “MVP: how to build a first version that fits into 6 weeks”. If you're torn between web, mobile and a PWA, let's decide together in mentorship.
