Few technical decisions attract more strong opinions than how to build a mobile app. Native purists, cross-platform advocates and web-first pragmatists can all point to success stories. They're all right — for their products.
The useful question isn't which approach is best. It's which approach fits what your app has to do, who has to maintain it, and how fast it needs to change.
The three options
- Native means separate apps written in Swift for iOS and Kotlin for Android. Maximum performance and immediate access to new platform features; two codebases to maintain.
- Cross-platform means one codebase — usually React Native or Flutter — compiled into both apps. Near-native results for most products at substantially lower cost.
- Progressive web apps are websites that can be installed to the home screen, work offline and send notifications. No app store, instant updates, but limited device access, especially on iOS.
Six questions that decide it
1. Does the app need deep device access?
Continuous background location, Bluetooth accessories, advanced camera processing or widgets and watch apps push you towards native or cross-platform with native modules. A PWA is rarely enough here.
2. How graphics-heavy is it?
Games, complex animation and real-time video benefit most from native. Forms, lists, maps and dashboards — the majority of business apps — are well served by cross-platform frameworks.
3. Do you need to be in the app stores?
Store presence matters for discovery and trust in consumer products. For internal tools or companion experiences to a website, a PWA can avoid review cycles entirely.
4. Who will maintain it?
A team of web developers can contribute to a React Native app far more easily than to two native codebases. Maintenance lasts much longer than the initial build; choose the option your team can sustain.
5. How often will it change?
Products still finding their fit change weekly. One codebase and over-the-air updates for JavaScript changes make that far cheaper.
6. What's the budget over three years, not three months?
Two native apps cost more than twice one app over time, because every feature, test and bug fix is done twice.
What not to decide on
Avoid choosing based on benchmark articles, a single developer's preference or what a well-known company used years ago. Frameworks move quickly; the constraints of your product don't.
Write down your answers to the six questions, share them with whoever will build the app, and ask them to argue with the conclusion. If the recommendation survives that conversation, you've made a sound decision.
Written by
DevTechnology Engineering