Most app projects begin with a technology question — native or cross-platform? The better first question is simpler: what does this app need to do on a phone that a good mobile website could not?
Answer that honestly and the technology choice usually makes itself. Get it wrong and you either pay twice for two codebases you didn’t need, or hit a wall six months in when the app needs something your framework can’t do well.
Start with the job the app does
Write down the three or four things a user must be able to do, and what each needs from the device. Does it use the camera, location in the background, Bluetooth, payments, push notifications, or work without a connection? Does it need to feel instant, or is it mostly forms and lists? These answers matter more than any framework comparison.
The three realistic options
- Native (Swift for iOS, Kotlin for Android): the best performance and the deepest access to the device, with two codebases to build and maintain.
- Cross-platform (React Native or Flutter): one codebase for both stores and a close-to-native feel for most business apps, with occasional native work at the edges.
- Progressive web app: installed from the browser, no store review and one codebase with the website — but more limited access to device features, and behaviour that varies between browsers.
When native is worth the cost
Native earns its price when the app’s value depends on the device itself: heavy graphics or animation, real-time audio and video, complex background work, or deep ties to the operating system such as widgets, wearables and system integrations. If the app is the product and every millisecond is felt, build it natively.
When cross-platform is the sensible default
Most business apps — booking, ordering, accounts, content, dashboards, events — are services delivered through a phone. For these, a cross-platform app lets one team ship to both stores, keeps features in step on iOS and Android, and costs far less to maintain. Where a native feature is needed, it can be added as a module without rewriting the app.
Choose the approach your team can maintain for years, not the one that wins the first demo.
Don’t forget what comes after launch
Apple and Google release new versions of iOS and Android every year, store policies change, and Android runs on thousands of different devices. Every app needs crash reporting, analytics, a release pipeline and someone keeping dependencies current. Budget for that from the start — it is part of the choice.
A simple way to decide
If the app’s core value depends on the device’s hardware or raw performance, go native. If it is a service delivered through a phone, start cross-platform. And if you need reach before people will install anything, start with a fast mobile website or a progressive web app, and earn the app once people come back to it.
