The native versus cross-platform argument generates more heat than any other question in mobile development, and for most products it should be short.
What you are actually choosing
Native means two codebases: Swift for iOS, Kotlin for Android. Two implementations of every screen, two sets of bugs, two release processes, and a genuinely better answer when the product leans on the platform itself.
Cross-platform — Flutter in our case — means one codebase producing both apps. One implementation, one set of bugs, one place to fix them, at the cost of a thin layer between your code and the operating system.
The four questions
Does the product depend on something platform-specific? Heavy camera or sensor work, background processing, deep integration with system features, sustained sixty-frame animation. If yes, native earns its cost. If your app is screens, lists, forms, payments and notifications — which is most business apps — it does not.
How big is the team that will maintain it? Two codebases need roughly twice the people, forever. Small teams that pick native usually end up with one platform quietly falling behind.
How fast does the product need to change? One codebase ships a change to both platforms at once. Two codebases ship it twice, and the second time is always later.
Are your users overwhelmingly on one platform? Check your website analytics before assuming. If it is ninety-ten, native for the ninety and nothing for the ten may beat cross-platform for both.
The honest downsides of cross-platform
It is not free. You depend on a framework and its release cycle. When a platform ships a new feature, you wait for support or write a bridge. Very unusual interface work sometimes fights the framework. And you need people who understand the platform underneath — a Flutter developer who has never met an Android lifecycle will produce an app that behaves oddly on exactly the phones your customers own.
What we do and why we say so
We build cross-platform, because marketplaces and service apps are the products we work on and one codebase is simply the cheaper honest answer for them. Our own marketplace runs that way, tested on real devices. When a project needs native we say so on the first call, including when that answer costs us the bigger quote — the alternative is discovering it in month three, which costs you far more than it costs us. Which way a given product should go is the first thing we settle, and the coverage table on the mobile page says plainly where cross-platform stops being the right answer.
Worth reading alongside it: what a mobile app costs, and what actually moves the number.