When is cross-platform right?
If the app fills forms, shows lists, sends data, receives notifications and talks to a backend — that is, behaves like most business apps — cross-platform is right. One codebase halves both the first build and every change after it.
The real gain arrives later: a feature is not written twice, a bug is not fixed twice, and the two platforms do not drift apart in behaviour.
When is native needed?
When the app pushes the device. Heavy graphics, real-time image processing, intensive sensor use or uninterrupted background work still favour native clearly.
There is a timing question too: when Apple or Google ships a new capability, native can use it on day one while cross-platform waits for the bridge. Most business apps never feel that difference.
How big is the cost difference really?
For the first release, native means two applications: two codebases and usually two specialisms. Cross-platform puts one team into both stores.
But the difference that matters shows in maintenance. An app is a living thing; operating system updates, store rules and new device sizes generate work every year. Carrying that load once instead of twice outweighs the gap in the initial build.
What question settles it?
One is enough: which of the things this app does cannot be done in a browser or a shared layer? If the answer is none, cross-platform is right.
If the answer involves real-time measurement through the camera, uninterrupted location tracking or heavy graphics, look at native. Mixing is also possible: most of the app shared, with only the critical part built natively.