The question is asked as a technical one. It is almost always settled on three things that are not technical at all: your budget, the size of your team and how long the application has to live.
What native really costs
Building native means two codebases, two skill sets, two test cycles and two fixes for every bug. The observed overhead sits between 60 and 90 % compared with a cross-platform base, and it does not disappear after delivery: it repeats with every change.
When native genuinely makes sense
It makes sense when the application depends heavily on hardware or graphics performance: real-time video processing, augmented reality, uncommon sensors, or when an in-house team already masters one platform and will take over maintenance.
What React Native and Flutter do well
Forms, lists, maps, notifications, offline mode, camera, payments: these needs, which make up the overwhelming majority of business applications, are covered without writing a line of native code. And when an exception appears, a native module grafts onto the shared base.
Choosing native “just in case” means paying twice for an option you will not use.
The criterion people forget
Who will maintain the application in two years? If the answer is “a small team” or “we don’t know yet”, cross-platform reduces the risk, because it halves the surface to maintain.
Our default recommendation
Start cross-platform, measure, and move to native only on the precise part that requires it. We have never yet had to rewrite an entire application for that reason.