Native, cross-platform or web: deciding on what actually differs
The choice is usually argued on performance, which is rarely the deciding factor for the applications most organisations build. What decides it is which platform capabilities you need, what your team can maintain, and whether you can afford to be wrong.
Part ofMobile App Development
Cross-platform frameworks are now good enough that performance only decides the question at the edges — heavy real-time graphics, sustained camera processing, low-latency audio. For a typical business application showing lists, forms and detail screens, all three approaches produce something that feels fine. So the decision has to be made on the things that genuinely differ.
The four options, honestly characterised
Start from the capabilities you actually need
This is the question that eliminates options fastest, and it should be answered before any framework comparison. Write the list, then check each item against each approach — specifically, not by reputation.
- Background execution — location tracking, syncing or processing while the app is closed. Heavily restricted everywhere and the most common source of "this cannot be done as we imagined"
- Hardware access — Bluetooth peripherals, NFC, biometric authentication, specific camera control
- Platform integration — widgets, share sheets, deep links, watch companions, contact or calendar access
- Offline operation — not a feature but an architecture; see the separate constraint it imposes
- Push notifications — supported broadly, but the reliability and behaviour differ more than expected
- Background file handling — large uploads and downloads that survive the app being suspended
Background execution is worth checking first because it is where product assumptions most often collide with platform reality. Both platforms restrict what runs when an app is not in the foreground, and no framework choice loosens those limits — a cross-platform app and a native app are equally constrained.
The shared-code figure is not the one quoted
Cross-platform proposals lead with a percentage of shared code. The number is usually accurate about lines and misleading about effort, because the unshared part is disproportionately difficult.
The team you have, and the team you can keep
This decides more real projects than any technical criterion, and it is frequently left out of the comparison entirely.
- Who maintains this in two years? An approach nobody on the team knows is a permanent hiring dependency.
- Can you hire for it locally? Native platform engineers and cross-platform engineers are different, differently priced markets.
- What does the rest of your stack look like? If the team is already strong in one language, sharing it lowers the ongoing cost materially.
- How many people will actually work on this? Two codebases with one engineer is a slow-motion failure regardless of the technical merits.
The last point is the practical one. Fully native is the strongest technical choice and it assumes enough people to sustain two codebases. Below a certain team size, choosing it means each platform gets half an engineer and both fall behind.
The cost of being wrong
A decision's quality includes how recoverable it is. These approaches differ sharply in what changing your mind later costs.
Defensible defaults
The second row is the one most often skipped. An organisation with a working web application and no mobile engineers can frequently meet the actual requirement — usable on a phone, installable, sends notifications — without entering the store ecosystem at all. That is worth eliminating deliberately rather than by omission, because the store route adds a review process, a release cadence and an account dependency to everything that follows.
Questions
Is native still worth it over cross-platform?
For heavy hardware use — Bluetooth peripherals, sustained camera processing, low-latency audio, background location — and where day-one support for new OS features is a requirement. For a typical business application showing lists, forms and detail screens, cross-platform frameworks now produce something that feels fine, so the decision should be made on capability access, team shape and maintainability rather than on performance.
How much code does cross-platform actually share?
The quoted percentage is usually accurate about lines and misleading about effort, because the unshared portion is disproportionately difficult: permission flows, push notification behaviour, background execution, any native module you write yourself, and store submission per platform. Budget for two test devices and platform-specific bugs regardless — one codebase does not mean one platform to test.
Can I just wrap my website in an app?
Both major stores reject applications that are little more than a browser pointed at an existing site, and the rejection arrives after you have built it. A wrapper needs genuine platform integration — notifications, offline behaviour, native navigation — to be accepted. If you have a working web app and no mobile team, a progressive web app often meets the real requirement without entering the store ecosystem at all.
What makes switching approach expensive later?
Local data. Changing approach with an installed base means every user's on-device data must migrate, in an update that may be installed months late or skipped entirely — so a technical decision becomes a data-loss risk. Designing the local store as something exportable from the start turns that eventual change from an incident into a project.