This question gets more debate than it deserves. For the large majority of apps, the answer is cross-platform, and the argument is settled enough that spending three meetings on it is usually the most expensive part of the decision.
Building native first and discovering you didn't need to is much harder to walk back.
What cross-platform actually gives up
React Native and Flutter both compile down to something close to native performance for the vast majority of interactions - lists, forms, navigation, animation. The gap that used to exist has mostly closed. What genuinely still favours native is deep integration with hardware the framework doesn't fully abstract yet: certain camera or Bluetooth features, some AR work, and apps where every millisecond of rendering is the product itself, like a high-end game.
If your app is content, commerce, bookings, a dashboard, or anything built around forms and lists - which describes most apps that get funded and shipped - cross-platform is not a compromise. It's the same product, built once instead of twice.
The real cost of building native anyway
Two codebases means two teams, or one team splitting its attention, and it means every feature gets built twice and can drift out of sync - the iOS version quietly falls a release behind Android, or a bug gets fixed on one platform and not the other because nobody remembered there were two places to fix it. For a startup validating an idea, that overhead is rarely worth paying before you know the app is worth having twice.
When to actually pick native
The honest trigger isn't "native feels more serious" - it's a specific technical requirement the cross-platform bridge can't clear. If you can't name that requirement precisely, you probably don't have one yet, and building cross-platform first is the version of this decision you can reverse later. Building native first and discovering you didn't need to is much harder to walk back.
Building something like this?
Let’s connect
