Flutter vs native is usually argued as a technology preference, which is why the argument never resolves. Framed properly it is not a preference at all: it is a question about your specific app, and it has a defensible answer in most cases within about ten minutes.
The question is what your app has to touch.
The cost you are actually choosing between
Two codebases means writing every feature twice, in two languages, by people with two different skill sets — and then maintaining both for as long as the app exists. That second half is the part that gets underestimated. The build is a one-off; the maintenance is every release, every OS update, every bug reproduced and fixed in two places, forever.
One codebase compiled to both stores means writing it once. The saving on the build is close to a halving. The saving on the decade after is larger, and it is the reason the decision deserves more thought than it usually gets.
So native has to earn that difference. Sometimes it does, comfortably. Usually it does not.
The four cases where native genuinely wins
Heavy, sustained graphics. Games, real-time video effects, anything holding a high frame rate while doing serious work. Cross-platform frameworks are fast enough for interfaces; this is not an interface problem.
Deep hardware or OS integration. Advanced camera control, background location running all day, Bluetooth peripherals with awkward protocols, health data, widgets and watch apps. Plugins exist for most of this and they are fine for ordinary use; when the hardware behaviour is the product, you want the platform API directly.
Platform-native feel as a product requirement. Some apps must feel unmistakably like they belong to their operating system — usually consumer products competing on polish in a crowded category. Cross-platform gets very close and does not get all the way.
You already have two native teams. An underrated reason. If you employ iOS and Android engineers, consolidating means retraining or replacing people, and the technical saving is dwarfed by the organisational cost.
If none of those describes your app — and for business tools, marketplaces, booking systems, internal apps and most content products none of them does — paying twice buys nothing a user will ever notice.
The objections worth taking seriously, and the ones that are out of date
"It will not feel native." Largely solved and easy to check for yourself: the framework is used by apps you already have on your phone. Where it is still true is the last few percent of interaction polish, which matters for some products and not for most.
"We will be stuck when we need a native feature." This is the real one, and the answer is that you are not stuck, you are slowed: a platform channel lets you drop into native code for the one screen that needs it. Plan for it rather than being surprised by it, and confirm that whoever you hire has actually done it.
"Upgrades will break things." True of every framework including the native ones, and the thing to settle before signing is whether framework upgrades sit inside your arrangement or arrive as a separate invoice. Apps become expensive to own when they are left untouched for two years and then need rescuing.
"It is a smaller talent pool." This cuts both ways and people only count one side. One cross-platform developer covers both platforms; two native developers cover one each. The pool is smaller and you need fewer of them.
The question to ask whoever builds it
Whichever way you go, one question separates teams that have shipped and maintained apps from teams that have only built them: how do you test on real devices, and how does a build get to the stores?
The answer you want describes a pipeline — builds produced automatically, distributed to testers on actual hardware, and submitted through a repeatable process rather than from somebody's laptop. Emulators hide exactly the problems that matter on phones: memory pressure on cheaper Android hardware, real network conditions, permission prompts behaving differently by manufacturer. A team that only tests on emulators will find those problems at the same time your users do.
How to decide in an afternoon
Write down every feature that touches hardware, the operating system, or the background. Not the whole feature list — just those. For most apps the list is short: push notifications, camera for a profile photo, maybe location when the app is open. All of that is well served cross-platform.
If the list is long, or if one item on it is the reason the app exists, that is your answer and you should pay for native without letting anyone talk you out of it.
Then ask the commercial question honestly: how many features do you expect to add in the two years after launch? If the answer is "many", the maintenance multiplier dominates everything and the decision is made. If the app is genuinely finished at launch — which is rare and does happen — the build cost matters more and the calculation is tighter.
Our own published apps are cross-platform, which is a position rather than a neutral observation, and it is why we would rather you checked the list than took our word for it. The trade-offs are argued out at length here, including the parts where we think native is right.
