Native or cross-platform? The honest test
Cross-platform is right for roughly seven business apps in ten. The interesting part is the other three — and the test that tells you which group you are in before you commit a budget.
Use Flutter or React Native unless the app depends on the phone being hardware rather than a screen. Continuous background location, Bluetooth peripherals, CarPlay or Android Auto, heavy camera work and on-device machine learning are the cases where native Swift and Kotlin earn the extra cost — and we quote them that way even though it is dearer.
The one-question test
Ask this: does the app need to keep doing something with the screen off?
If no — the app is forms, lists, maps, capture, payments and dashboards that run while someone is looking at them — cross-platform will serve you well and cost roughly 60–70% of the native equivalent for both platforms.
If yes — tracking a vehicle for an eight-hour shift, staying paired to a scanner, running the camera continuously — you are fighting the platform's background execution rules, and every plugin between you and the operating system is a liability. Go native.
The comparison, on criteria that decide real projects
| Criterion | Flutter / React Native | Native Swift & Kotlin |
|---|---|---|
| Cost for both platforms | One codebase — roughly 60–70% of native | Two codebases, two engineers, two release cycles |
| Standard business UI | Indistinguishable to users in practice | Marginally better, rarely worth the difference |
| Continuous background location | Fights the platform; battery and reliability suffer | Correct choice — full control of background modes |
| Bluetooth / hardware peripherals | Plugin quality is a risk you inherit | Direct access, predictable behaviour |
| Heavy camera or on-device ML | Workable with native modules | Better performance and thermal behaviour |
| CarPlay, Android Auto, watch apps | Native code required regardless | Native from the start avoids a hybrid mess |
| Speed to first release | Typically 3–5 weeks faster to both stores | Slower, unless you only need one platform |
| Long-term maintenance | One upgrade path, occasional plugin churn | Two upgrade paths, but fewer surprises |
Scroll the table sideways to compare both columns.
Flutter or React Native?
If cross-platform is the right call, the choice between the two is usually about your team rather than the technology.
- Flutter when the app is forms, lists, maps, capture and payments — which is most business software. Rendering is consistent across devices, which matters when your users carry a wide spread of hardware.
- React Native when you already have a React web team. They can review the code and eventually own it, and that continuity is worth more than any framework benchmark.
We will quote the more expensive native option when the app genuinely needs it, and explain why, rather than shipping something that drains a battery by lunchtime. Recommending cross-platform for a tracking app is how a project fails eight weeks after launch.
The mistakes that cost more than the framework choice
In practice, the native-versus-cross-platform decision is rarely what sinks a mobile project. These three are.
Testing on the wrong phones
Built and reviewed on a current iPhone, then deployed to warehouse staff carrying four-year-old Android handsets with cracked screens and 2GB of usable RAM. Ask for the actual device inventory in week one and test on the worst device in it, not the best.
Treating offline as a checkbox
"It should work offline" hides a week of decisions. What happens when two people edit the same job while both are offline? Whose version wins, and does the loser find out? Those conflict rules belong in the design document, agreed with you, not decided by whoever implements the sync loop.
No budget for the annual OS cycle
Apple and Google both force SDK and target-API updates roughly yearly. Miss one and you cannot ship updates at all until it is done — usually discovered when an urgent fix is needed. This applies equally to native and cross-platform, and it is real, recurring work.
What actually drives the cost
Three things, in order of weight. One platform or both is the first and largest fork — cross-platform collapses it, native doubles it. Offline support adds a sync layer and a set of conflict rules that have to be agreed rather than assumed. And whether the backend already exists: it is usually the larger half of the work, and the part clients most often leave out of a budget. An app with nothing behind it is a form.
We quote after a paid discovery that splits the mobile and backend numbers separately, so you can see which half is driving the total. Full detail, including the store submission process, is on our mobile app development page.
Related reading
Tell us who uses the app, and where they're standing.
Those two answers decide native versus cross-platform, the offline strategy and half the budget. An engineer replies within one business day with a recommendation and a range.
- Email — [email protected]
- Phone / WhatsApp — +91 817 979 7732