An organization launching a mobile app faces three main options: build a native app for each platform, use a cross-platform framework that shares a single codebase between iOS and Android, or build a progressive web app that can be installed from the browser. No option is better in absolute terms; the right one depends on your context.
The three approaches at a glance
- Native: a separate app for iOS (Swift) and for Android (Kotlin), as close as possible to each system
- Cross-platform: a shared codebase, for example with React Native or Flutter, compiled for both systems
- Progressive web app: a web application that can be installed on the home screen and work offline thanks to service workers
Criterion 1: device access needs
If your app makes heavy use of the camera, Bluetooth, specialized sensors or recent system features, a native or cross-platform approach is the way to go. Progressive web apps have come a long way, but their hardware access remains more limited, especially on iOS.
Criterion 2: budget and timelines
Building two native apps means maintaining two products. A cross-platform approach generally reduces development and maintenance effort while offering an experience very close to native for the vast majority of business apps. A progressive web app is often the fastest to deliver when a website already exists.
Criterion 3: distribution
Being in the App Store and Google Play reassures users and helps with discovery, but every update goes through a review process. A progressive web app is distributed with a simple link and updates instantly, which suits internal tools and services aimed at a broad audience.
Criterion 4: working offline
For field teams — inspectors, technicians, regional agents — offline mode is not optional. All three approaches can store data locally, but native and cross-platform apps offer finer control over synchronization, conflict management and encrypted storage.
Our rule of thumb
For a typical business app, cross-platform offers the best trade-off. Native is justified for demanding hardware or graphics requirements; a progressive web app for a simple need, broad distribution or a tight budget.
Criterion 5: long-term maintenance
An app lives for several years. Assess the availability of skills on the market, the maturity of the chosen ecosystem and the cost of annual operating system updates. A technology that is very popular today but poorly supported tomorrow can be expensive.
Three typical scenarios
- Citizen appointment booking app: a progressive web app, quick to deploy and usable without installation
- Field inspection app with geotagged photos and offline mode: cross-platform
- App using augmented reality or industrial sensors: native
The right choice is made during scoping, by testing these criteria against your real users and your roadmap. A short proof of concept often clears up the last doubts before committing the development budget.