For most business systems the answer to the native app vs web app question is a web application: one piece of software that runs in the browser on every phone, tablet and computer, with nothing to install and one version to maintain. A native app earns its extra cost when the software must work for long periods without a signal, keep running while the phone is locked, or use hardware that a browser cannot reach. There are also two options in between, and for an internal system or a customer portal one of them is sometimes the best fit.
The four options
A web application runs in the browser. Staff or customers go to an address and sign in. It is built once, and a responsive layout (one that rearranges itself to fit the screen) makes the same screens usable on a phone and on a desktop monitor. Updates are released on the server, so everybody is on the current version the next time they load a page.
A progressive web app, usually shortened to PWA, is a web application with some additions. It can be added to the phone’s home screen with its own icon, open full screen without the browser’s address bar, carry on working when the connection drops and send notifications. It is still one set of code and it does not need an app store.
A cross-platform app is installed like a native app, but the iPhone and Android versions are built from one shared set of code. The main tools in 2026 are Flutter (from Google), React Native (from Meta), .NET MAUI (from Microsoft) and Kotlin Multiplatform (from JetBrains). If you have an existing app or an old quotation that mentions Xamarin, note that Microsoft ended support for Xamarin on 1 May 2024 and names .NET MAUI as its successor.
A native app is written separately for each platform with the tools Apple and Google provide: Swift for iPhone and iPad, Kotlin for Android. It has the fullest access to the device and the most polished feel, and it means building and maintaining two applications.
How the four compare
| Web application | Progressive web app | Cross-platform app | Native app | |
|---|---|---|---|---|
| How people get it | Open a link | Open a link, then add it to the home screen if they wish | App store, or pushed to company devices | App store, or pushed to company devices |
| Code to maintain | One application | One application | One, plus some work per platform | One per platform |
| Works without a signal | No | Yes, for the parts designed for it | Yes | Yes |
| Notifications | By email or text message | Yes; on an iPhone only after it is added to the home screen | Yes | Yes |
| Phone hardware and background work | What the browser allows | What the browser allows | Nearly everything | Everything |
| Releasing a change | Immediate | Immediate | A new version through the store | A new version through each store |
| Relative cost | Lowest | A little more | More | Most |
What a web application can do now
The old argument for native apps was that browsers could not do much. That is out of date. On a current phone a web application can take photographs, scan a barcode with the camera, read the device’s location once the user gives permission, capture a signature on the screen, accept file uploads and hold data on the device for use offline.
That covers a large share of what business software asks of a phone: an engineer completing a job sheet, a driver recording a delivery, a customer checking an order in a portal, a manager approving a request from home.
The limits are where the decision is made.
- It only runs while it is open. A web page cannot record a vehicle’s route or exchange data with the server while the phone is locked in a pocket.
- Some hardware is out of reach. The compatibility tables kept by MDN, the standard reference for web developers, show that Safari and Firefox do not support connecting to Bluetooth devices from a web page. On an iPhone that rules out talking to a Bluetooth label printer or measuring instrument from the browser.
- Offline working takes careful design. A PWA copes well with gaps in coverage, such as a plant room or a rural lane. In our judgement it is a weaker choice for a whole shift without a connection and a large amount of data to carry.
- Notifications on iPhones depend on the user. Apple supports them for web apps that have been added to the home screen. Staff can be shown how to do that. Customers mostly will not bother.
When an installed app is worth the extra cost
An installed app, cross-platform or native, is justified when at least one of these is true:
- people work for hours with no signal and need the full system with them;
- the software must record location or sync data while the phone is locked or another app is in use;
- it must connect to Bluetooth equipment, read NFC tags or run on rugged handheld scanners;
- prompt notifications are central to the job, and the recipients are customers;
- your customers expect to find you in the app store, which matters for a consumer brand and rarely for an internal system.
When one of these applies, a cross-platform app is usually the sensible form for business software: one team and one set of code for both stores. If the rest of your system is built on Microsoft’s .NET, .NET MAUI lets the app share the C# language and some code with it. Building separately for each platform is worth it when the app is itself the product being sold, or when it works the device hard, with heavy graphics or the latest camera features.
Even then, the office side of the system (administration, reporting, setting up jobs and users) is better built as a web application. The app and the web application both talk to the same server and database, and the business rules live there. Our article on which to develop first, app or website covers the order to build them in.
The costs that come with app stores
The build cost is only part of the difference. An installed app brings running costs that a web application does not have.
- Developer accounts. Publishing needs accounts with Apple and Google. Make sure they are registered to your company and not to your supplier, so that you can change supplier without losing the app.
- Review. Apple reviews apps before release, including custom apps that are distributed privately to a single organisation and never appear in the public store. Allow time for it in any deadline.
- Old versions in use. People update when they choose to, so the server has to keep working with older versions of the app for a while after each release.
- Yearly upkeep. Apple and Google both raise the minimum standards for apps as new versions of iOS and Android come out. Google Play, for example, stops offering an app to people with newer phones if it has not been updated to target a recent version of Android. An app needs maintenance even when nothing in your business has changed.
These are the reasons the gap in cost between a web application and an app widens over the years, and why the cost of developing an app should be looked at over its whole life.
How to make the decision
List the tasks the software must support and where each one is done. The software project planning worksheet has a place for this. Against each task, mark whether it has to work with no signal, with the phone locked, or with a piece of hardware.
If nothing is marked, commission a responsive web application. That is where most internal systems should start, and it is the normal form for a customer portal. If the only marks are short gaps in coverage, or notifications to your own staff, a progressive web app will do the job. If a task needs the phone itself, plan a cross-platform app for those tasks and a web application for everything else.
Then ask any supplier who recommends a native app one question: which task on the list cannot be done in a browser? If they cannot name one, you are being quoted for two or three applications where one would do.