Every mobile project starts with the same argument, and it is almost always framed wrongly. The question is not which technology is better. It is which set of trade-offs the product can live with for the next three years.
Does the app depend on platform features that move fast?
Widgets, live activities, deep camera control, background location, health data. Anything Apple or Google ships in a new OS version arrives in native SDKs on day one and in cross-platform wrappers whenever someone gets round to it. If your roadmap lives there, native wins before the conversation starts.
How many screens are genuinely platform-specific?
Flutter saves the most on apps that are mostly forms, lists and dashboards with one shared design language. It saves the least on apps that are supposed to feel like they belong on the platform, because you end up writing the differences by hand anyway and paying for the abstraction twice.
Who maintains it in year two?
This is the question clients skip and regret. One Flutter developer can keep both apps alive. Two native apps need two skill sets, or one very patient person. If the in-house team after handover is small, that matters more than any rendering benchmark.
What happens if the answer turns out to be wrong?
Keep business logic, API clients and models in a layer that does not know what draws the screen. We have rewritten a Flutter UI on top of an unchanged domain layer in six weeks. Rewriting an app where networking calls live inside widgets takes a great deal longer.
In practice we recommend Flutter more often than not, and we are explicit that it is a trade, not a free lunch.
