Every mobile kickoff call ends up at the same question: Flutter, or two native codebases? The comparison charts on the internet are not wrong, exactly — Flutter really does share more code, native really does get day-one access to new platform APIs. They are just answering the wrong question. The chart compares frameworks. You are choosing for a specific team, a specific budget, and a specific app that has to still be maintainable in year two.
What the charts leave out
A feature comparison treats "camera access" or "background location" as a checkbox. In practice, the gap is rarely whether a plugin exists — it is how recently it was touched, how many open issues it carries, and whether your team can read Kotlin or Swift well enough to patch it themselves when it breaks on a new OS release. We have shipped Flutter apps that never touched a native API directly, and we have shipped Flutter apps where a third of the sprint went into a platform channel because the plugin ecosystem did not cover a payment SDK the client required.
So the first real question is not "does Flutter support X" but "how much of this app is X". If the product is mostly forms, lists, and a chat screen, Flutter's shared codebase pays for itself quickly. If the product's reason to exist is deep camera processing, ARKit, or a Bluetooth stack with vendor-specific quirks, native access stops being a nice-to-have and starts being the critical path.
Team shape decides more than tech
We size this by asking one blunt question: does the client have, or plan to hire, in-house iOS and Android engineers after we hand the project over? If the answer is no — which is most of our clients — two native codebases means two languages, two build pipelines, and two sets of platform-specific bugs for a team that only budgeted for one. Flutter's single codebase is not just faster to build; it is dramatically cheaper to keep alive.
If the client already runs a native mobile team, the calculus flips. They are not paying twice for the same feature — they already have the people. In that case Flutter adds a second stack for the team to maintain expertise in, without removing the native one, since some part of the product usually still needs a native module eventually.
The year-two question
Almost nobody asks this at kickoff, but it decides more launches than anything else: who fixes this app in eighteen months, after the agency that built it has moved on? Flutter's tooling has matured to the point where a mid-level engineer can be productive on an unfamiliar Flutter codebase within a week. Two native codebases require two specialists, or one generalist doing an unfamiliar job in whichever platform they know less. We have inherited both kinds of projects, and the maintenance cost difference is not subtle.
Where we land on this
Our default for client products without an in-house mobile team is Flutter, unless the product's core value depends on platform-specific capability that the plugin ecosystem does not cover well — at which point we scope a proof of concept for the risky feature before committing to a framework for the whole build. That fifteen-hour spike has saved more than one project from a mid-build framework switch.
- Mostly CRUD, forms, and content screens → Flutter, almost every time.
- Heavy camera/AR/Bluetooth work → prototype the risky feature natively first.
- Client already runs native mobile engineers → let their roadmap decide, not ours.
None of this is a framework opinion. It is a maintenance-cost opinion wearing a framework's clothes.
