Native or cross-platform: how to decide

This decision is usually made on taste and then justified afterwards. It is decidable, and three questions settle most cases.

How much of the app talks to the device? If the answer is camera, filesystem and notifications, cross-platform handles all of that well and you will not notice a difference. If the answer includes background location tracking, Bluetooth peripherals, precise audio, or anything the platform vendors change frequently, you will spend your savings on bridging code and then spend more maintaining it.

How much of the app is the interface? An app whose value is data entry, lists and forms is mostly business logic, and sharing that logic across platforms is a real saving. An app whose value is how it feels — gesture-driven, heavily animated, competing with the platform's own apps — is mostly interface, and interface is the part that shares worst.

Who will maintain it in two years? One cross-platform codebase can be maintained by a smaller team than two native ones. That is the strongest argument for cross-platform and it is often the decisive one, particularly for internal tools where a single developer has to keep everything running.

A fourth consideration is worth naming because it is easy to ignore. Cross-platform frameworks add a dependency on someone else's release schedule. When a platform makes a breaking change annually, you wait for your framework to catch up before you can. Native has its own version of this problem but it is usually shorter.

There is no default. An internal field-operations app is nearly always better cross-platform. A consumer app whose competitors are polished is usually better native. Most business apps sit closer to the first than people expect, which is why cross-platform has become the reasonable starting assumption rather than the compromise it used to be.