When a business decides it needs a mobile app — for technicians, sales staff, delivery drivers or customers — one of the first technical questions is how to build it. Should you build separate native apps for iPhone and Android? Use a cross-platform framework that produces both from one codebase? Or skip the app stores entirely with a progressive web app? Developers often have strong opinions, and the arguments online are full of jargon. This guide explains the options in plain language and gives you a practical way to decide.
The three approaches in one paragraph each
Native apps are built separately for each platform, using the tools Apple and Google provide: Swift for iOS and Kotlin for Android. You get two codebases, two sets of screens and, often, two teams. In return you get full access to every device feature on the day it is released, and the best possible performance.
Cross-platform apps are built once, using a framework such as Flutter or React Native, and compiled into real installed apps for both iOS and Android. Most of the code — screens, business rules, data handling — is shared. Where a platform-specific feature is needed, a small piece of native code can be added.
Progressive web apps (PWAs) are websites built to behave like apps. Users open them in a browser and can add them to their home screen. They can work with limited connectivity, send notifications on most devices and use the camera, but they do not go through the app stores and have more limits on background activity and device access.
What most business apps actually need
Before comparing technologies, list what your app must do. For most business apps, the list looks something like this:
- Log in securely and show each user their own jobs, orders, tasks or accounts.
- Show lists and details, and let users fill forms and checklists.
- Take photos, capture signatures and scan barcodes or QR codes.
- Record GPS location at key moments, such as check-in at a site.
- Work without a network connection and sync later.
- Receive push notifications.
- Talk to a web back-end where office staff manage the same data.
All three approaches can handle most of this list. The differences appear at the edges: how well the app works offline, how reliably it can run in the background, how it handles unusual hardware, and how much it costs to build and maintain over several years.
When native makes sense
Native development is the right choice when the app itself is the product and its performance or device integration is a competitive advantage. Examples include apps with complex animations or graphics, apps that process video or audio on the device, apps that depend on the newest platform features, and apps that talk to specialised hardware over Bluetooth with strict timing. It can also make sense when a company already has separate iOS and Android teams.
The trade-off is cost and speed. Two codebases mean two implementations of every feature, two sets of bugs and two release cycles. For a business app with a modest budget, this often means fewer features or slower progress.
When cross-platform makes sense
For the majority of business apps — field service, sales, inspections, deliveries, staff self-service, customer ordering and booking — cross-platform development is usually the best balance. One team builds one codebase, features arrive on both platforms at the same time, and the total cost of building and maintaining the app is lower. Modern frameworks produce apps that look and feel native to users, with smooth scrolling, platform-appropriate controls and good performance.
Cross-platform apps also handle offline work well. Data can be stored on the device, edited without a connection, and synchronised with the server when the network returns — essential for technicians in basements, plant rooms and rural sites.
The limitations are real but narrow: a brand-new platform feature may take time to appear in the framework, and a few hardware integrations need extra native code. A good development partner will identify these during planning, not after launch.
When a progressive web app is enough
A PWA is a good choice when users mostly work on a stable connection, the app is mainly forms, lists and dashboards, and you want the simplest distribution and maintenance. Examples include management dashboards, approval apps, internal request forms, simple customer portals and booking pages. Updates reach everyone instantly, with no app store review, and one codebase also serves desktop users.
PWAs are weaker when the app must run in the background (for example, tracking a route), work fully offline for long periods, or use device features that browsers restrict. On iPhones in particular, some capabilities are more limited than on Android. For customer-facing apps, not appearing in the app stores can also reduce discovery and trust.
Comparison at a glance
| Factor | Native | Cross-platform | PWA |
|---|---|---|---|
| Codebases | Two | One (plus small native parts) | One, also serves desktop |
| Build and maintenance effort | Highest | Medium | Lowest |
| Offline work | Excellent | Excellent | Good, with limits |
| Background tasks and location | Full | Full, with plugins | Limited |
| App store presence | Yes | Yes | No (installed from browser) |
| Typical fit | Graphics-heavy or hardware-heavy apps | Most staff, field and customer apps | Dashboards, approvals, simple portals |
Questions to decide with
- Who uses the app? Your own staff on company phones, or customers on any device? Customer apps usually need app store presence and polish; staff apps need reliability and speed of use.
- Where do they use it? If users work in places with poor coverage, strong offline support is non-negotiable.
- Does it need to run in the background? Continuous location tracking or long uploads favour installed apps.
- Is there unusual hardware? Bluetooth printers, scales, meters or sensors should be tested early, whichever approach you choose.
- How long will you run the app? Over five years, maintenance usually costs more than the first build. One codebase is easier to keep up to date with new phone and operating system versions.
- Do you also need a web version? If office staff need the same screens on desktops, a PWA or a shared web back-end with a cross-platform app may cover both.
Don't forget the back-end
Business owners often focus on the app itself, but most of the value sits behind it: the web application where office staff schedule work, approve requests and run reports, the database, the user management and the integrations with other systems. Whatever approach you choose for the app, plan the back-end and admin panel with equal care. A beautiful app connected to a weak back-end will frustrate both users and managers.
Common mistakes
- Choosing technology before workflows. Decide what users must do and in what conditions, then pick the approach.
- Ignoring offline until testing. Offline behaviour shapes the whole data design; adding it late is expensive.
- Underestimating app store work. Store listings, privacy declarations, screenshots and review cycles take time. Plan for them.
- Testing only on new phones. Field staff often use older, cheaper Android devices. Test on the devices your users actually have.
- Forgetting updates. Phone operating systems change every year. Budget for regular maintenance releases.
Example
A service company needed an app for 40 technicians: job lists, checklists, photos, customer signatures, spare-part usage and GPS check-in, working in basements and plant rooms with no signal. A customer booking app was also planned for later. The team chose a cross-platform app with an offline-first design and a web admin panel for dispatchers. Both Android and the few iPhones in use were covered from day one, and when the customer booking app was added, much of the code and design was reused.
Summary
For most business apps, a cross-platform app with a solid web back-end gives the best balance of cost, speed and capability. Choose native when performance or deep device integration is the product itself, and choose a PWA when the app is mostly forms and dashboards used on a reliable connection. Whatever you choose, decide based on your users, their working conditions and the years of maintenance ahead — not on which technology is fashionable.
Frequently asked questions
Is a cross-platform app slower than a native app?
For most business apps — forms, lists, photos, maps, scanning and sync — users will not notice a difference. Performance gaps show up mainly in graphics-heavy apps, games, and apps that do heavy processing on the device.
Can a cross-platform app use the camera, GPS and barcode scanning?
Yes. Modern cross-platform frameworks support camera, GPS, barcode and QR scanning, push notifications, file storage and offline data. Unusual hardware may need a small amount of native code.
Do we need to publish in the App Store and Play Store?
For customer apps, usually yes, because that is where customers look. Internal staff apps can also be distributed privately, depending on your devices and how they are managed.
Is a progressive web app enough instead of an app?
Sometimes. If users mainly need forms, lists and dashboards and have a reliable connection, a PWA can be enough and costs less to maintain. Apps that need strong offline support, background location or deep device features are better as installed apps.
Can we start with one platform and add the other later?
Yes, but with a cross-platform approach you usually get both platforms from the same code, so starting with only one rarely saves much.
