In this guide 6 sections
Choose by the device features you need. An installable web app suits forms, lists and light camera use, while React Native and Flutter suit one team shipping to both stores. Native Kotlin or Swift suits heavy background location, Bluetooth hardware, vendor scanner libraries and long offline stretches in a basement or a cold store.
List the device features before you list the tools
Frameworks are only a means. List what the app must do on the handset: scan a barcode, photograph a damaged parcel, keep working in a basement and track a van with the screen off. Buzz a phone when a job lands.
Mark each item must have or nice to have, because a nice-to-have feature should never decide the technology, while a must-have often does. Be strict.
Then note the phones in staff pockets. A three-year-old budget Android with little free storage behaves very differently from a new flagship, and your staff probably carry the former. Ask which Android versions and which iPhones sit in the drawer, and whether drivers use their own phones or a company handset that you can lock down.
- Camera and document capture
- Barcode or QR scanning
- Offline storage and later sync
- Background location
- Push notifications
Where an installable web app is enough
A progressive web app is a website that installs to the home screen, caches its pages for patchy signal and opens full screen without the browser bar. It needs no store review. Updates reach everyone the moment you publish. Nothing to install twice.
Forms, job lists, approvals and dashboards run well, and so does basic photo upload from the phone camera on a site visit or a delivery round. Long background tasks, some Bluetooth devices and reliable push on older iPhones are weaker spots, and users on shared handsets may clear the cache.
For a back-office team on laptops, with a few shared tablets in the stockroom and nothing needing the phone’s radios, it is often the cheapest honest answer.
Where React Native and Flutter fit
Both let one team write one codebase for Android and iPhone, with React Native using JavaScript and each phone’s controls while Flutter uses Dart and draws every screen itself. The finished apps feel alike.
Both reach the camera, scanner, files and push without trouble, and both can keep data in a local database and sync it later. Background location works too, but it needs testing against each maker’s battery rules, since an app that tracks well on one handset can be stopped on another.
Choose the one whose developers your vendor already employs, because a skilled team in either beats a keen beginner in the other, whatever the conference talks say.
- One team, two store listings
- Good camera and scanner support
- Offline database with sync
- Store review for every release
When to write native Kotlin or Swift
Go native when the app lives close to the hardware, as with a handheld scanner that ships a vendor library, a Bluetooth printer or a smart lock. A driver app tracking location through a full shift lands here as well, because the phone stays in a pocket with the screen dark.
You pay for two codebases, usually two skills and slower changes, and in return you get steady behaviour under strict battery limits and first access to new phone features. That is a real trade.
Make the vendor name the exact feature that forces native, and record it in the proposal with the handset model it was tested on. If they cannot, a cross-platform build probably works.
Run a one-week test on your worst handset
Ask for a thin trial of your hardest feature in the two leading options, each with one screen, one task and a test script written by your own supervisor. Install both on the oldest phone your staff carry and on a budget handset from the local phone shop, then hand each to a driver for a week.
Check start-up time, scanning speed in poor light, a full night offline and the battery drop after an hour of tracking. Numbers from your own phones outweigh any comparison chart a vendor shows, so record them on the sheet in front of the vendor’s developer.
Pick the option that passes. Then write the reason in the contract notes, with the test dates and handset models, so that a later developer knows why you chose it.
App technology decision sheet
A one-page grid. Rows list your device needs: camera, scanning, offline use, background location, push, store approval and update effort, while columns hold web app, React Native, Flutter and native. Each cell takes pass, partial or fail from your own handset trial, and a notes strip records results on the oldest phone.
Open a blank worksheet to printQuestions owners ask
Is a PWA good enough for a business app?
Often yes. Forms, lists and approvals used on laptops or modern phones suit it well, but it is weaker on long background tasks, some hardware and push on older iPhones. Test your hardest feature first.
Is Flutter or React Native better?
Neither wins everywhere. Pick the one your vendor’s team knows well, and check your key device feature in a one-screen trial, because team skill matters more than the framework does.
Does native always perform better?
Native gives the most control over hardware and battery behaviour, but for ordinary screens and forms a well-built cross-platform app feels the same to staff on the same handset. Measure before you pay for two codebases.
Can I change technology later?
You can, though it means rewriting every screen. Keep the server, database and interfaces separate from the screens, and a later switch costs far less, because the business rules, the stored data and the integrations carry over.