In this guide 6 sections
For most business apps, React Native or Flutter is enough and one team can ship to both stores. Go native when you need deep hardware access or heavy graphics. Whichever you choose, judge it by offline behaviour, cheap Android phones and who can maintain it in three years.
What you are really buying
Every route ends in two store listings. You will keep an Apple developer account and a Google Play account, answer review comments and update the app whenever a new Android or iOS version changes a rule.
That upkeep is the same for all three options. What differs is how many codebases you carry. React Native and Flutter give you one. Native gives you two, in Kotlin and Swift. Add a yearly test pass on new Android and iOS releases to your plan. A phone update can break a camera screen overnight and nobody warns you. Plan for it. Write the offline needs as plain sentences, for example that a driver must close a delivery with no signal and see it sync later. Vague words hide very different amounts of work.
React Native in plain terms
React Native uses JavaScript or TypeScript and real native widgets. Teams that already build the web side in React can share skills and sometimes share logic. Libraries exist for camera, barcode, maps and push notifications.
It sits well with a Node.js back end and a Next.js portal. Hiring is easier because JavaScript developers are common.
The weak spot is upgrades. A major React Native release can break a plugin that nobody maintains any more. Ask which plugins the app will depend on and when each was last updated. An abandoned scanner library quietly becomes your own problem to maintain. Ask how the team handles a screen that works on one Android maker’s phone and fails on another. That fault reaches production within the first month more often than owners expect.
- Shared skills with a React web team
- Large plugin library for scanners and maps
- Upgrade work each year, sometimes painful
- Good fit for forms, lists and field data entry
Flutter in plain terms
Flutter uses the Dart language and draws every pixel itself. Screens look identical on every phone, which pleases designers. Animation is smooth even on modest hardware.
Dart developers are fewer than JavaScript ones. That matters in year three if your first team moves on. Some native features still need a small piece of Kotlin or Swift code.
Flutter suits apps with a custom look, such as a catalogue or a visual order builder. Check one thing before you commit. Does the Dart team stay? Hot reload pleases developers, but your question differs: can a stranger read this code in three years and fix it without the original author?
When native is worth the cost
Choose Kotlin and Swift when the app leans on Bluetooth printers, NFC cards, background location, or the newest camera features. Native code reaches those first and fails least.
It costs more because two teams write two apps. Features land on one platform before the other. Budget for that gap.
A scan heavy warehouse app with rugged handhelds may justify it. A sales order app rarely does. Printing is the usual trap. A Bluetooth label printer or thermal receipt printer often ships with a native software kit and no tidy cross platform library. Two codebases also mean two release notes, two review queues and two bug lists. A small business should count that honestly before choosing the premium route.
Test on the phones your staff really carry
Entry level Android phones with little memory expose slow apps fast. Test on two of them, not only on the newest iPhone. Switch off the network and try the app again.
Offline use is the real divide. Ask each vendor how orders are stored on the phone, how conflicts are settled and how a failed upload is shown to the user. Ask to see it, not to hear it.
Then list who will maintain the app in three years and book that person into the decision. Put the scorecard in front of the person who will own the app after launch, and let that person break any tie. Ask for a small paid prototype of the hardest screen on two options, and compare the results on a cheap handset.
- Cheap Android handset in the test pack
- Airplane mode run of the main task
- Camera and barcode scan in poor light
- Named maintainer and a handover plan
App route scorecard
Grid on a single sheet, with React Native, Flutter and native as columns. Rows cover camera and barcode, offline mode, cheap Android speed, printer or NFC need, hiring pool, store upkeep and three year maintainer. Each cell takes a score and a note.
Open a blank worksheet to printQuestions owners ask
Is a web app enough instead of any of these?
Often yes. A responsive web app or a progressive web app covers forms and lists. You need a store app for deep camera, background tasks or reliable offline work.
Which is cheaper, React Native or Flutter?
Both use one codebase, so build effort is similar. The real difference is who you can hire and keep. Price the maintenance, not only the first release.
Can one app serve Android and iOS staff together?
Yes, with React Native or Flutter. Expect small platform specific fixes. Plan test time on both systems for every release.
Do we have to rebuild if we pick wrong?
Not entirely. The back end and API stay. Only the app layer is rewritten, which is why a clean, separate API matters from the start.