Native or cross-platform: decide from the requirements
The native-versus-React-Native argument is usually conducted as a matter of taste. It should be a short conversation about what the app has to touch.
The question comes up in the first week of every mobile project, and it tends to get answered by whichever technology the loudest person in the room used most recently. There is a better way to decide, and it takes about an hour.
Write down what the app touches
Cross-platform frameworks are excellent at screens, navigation, forms and API calls. They get progressively less excellent the closer you get to the hardware.
Go native when the app depends on:
- Sustained Bluetooth work, especially background scanning
- Camera pipelines beyond "take a photo"
- Background location or long-running background execution
- Tight platform integration: widgets, watch apps, CarPlay, App Clips
- Anything where a new OS release changing behaviour is a business risk
Go cross-platform when the app is mostly forms, lists, auth and API traffic - which, honestly, is most business apps.
The maintenance argument cuts both ways
One codebase sounds like half the maintenance. In practice it is one codebase plus two platform-specific edge-case files plus a dependency on the framework keeping pace with OS releases.
That is still usually less than two native codebases. But it is not half, and budgeting as if it were is where cross-platform projects go wrong.
The honest tiebreaker
Who maintains it after we leave? A cross-platform app handed to a team with two native developers is a bad fit regardless of the technical merits, and a native pair handed to one generalist is worse.
Match the choice to the team that inherits it. That constraint is usually more binding than anything on the feature list.