The right choice depends on your users, your features and your budget, not on what’s fashionable. Here’s a clear way to decide between native, cross-platform and web.
“Should we build native, cross-platform, or just a web app?” is one of the first questions on any new product. It affects your budget, your timeline, the team you hire, and how the product feels in people’s hands.
There’s no universally right answer. But there is a right answer for your product, and it usually becomes clear once you look at a few specific questions. Let’s start with what each option actually means.
The three options in plain English
Native apps
Separate apps written specifically for each platform: Swift (with SwiftUI) for iOS, and Kotlin (with Jetpack Compose) for Android. Each uses the platform’s own tools and design conventions.
Strengths: best performance, immediate access to every new device feature, and the most “at home” feel on each platform.
Trade-offs: two codebases, often two teams, and features built twice. Higher cost to build and maintain.
Cross-platform apps
One shared codebase that produces real iOS and Android apps, published in the app stores. The main frameworks are React Native (JavaScript/TypeScript), Flutter (Dart), and Kotlin Multiplatform, which shares business logic while letting the interface be native or shared.
Strengths: most code written once, faster delivery, one team, and performance that’s more than good enough for the large majority of business apps.
Trade-offs: occasional platform-specific work, dependence on the framework keeping up with new OS features, and some extra effort for heavy graphics or unusual hardware.
Web apps and PWAs
Applications that run in the browser. A Progressive Web App (PWA) adds app-like features: it can be installed on the home screen, work offline, and send push notifications. On iPhone, web push requires the user to add the app to their home screen first.
Strengths: one codebase for every device including desktop, no app store approval, instant updates, and links that work everywhere. Usually the lowest cost.
Trade-offs: limited access to some device features, less presence in app stores, and a slightly less “native” feel, particularly on iOS.
Side-by-side comparison
| Native | Cross-platform | Web / PWA | |
|---|---|---|---|
| Codebases | 2 (iOS + Android) | 1 (mostly) | 1 |
| Relative build cost | Highest | Medium | Lowest |
| Time to market | Slowest | Fast | Fastest |
| Performance | Best | Very good | Good |
| Device features | Full | Nearly full | Partial |
| App store presence | Yes | Yes | Limited |
| Desktop users | Separate build | Possible, varies by framework | Built in |
| Updates | Store review | Store review* | Instant |
*Some cross-platform setups allow small over-the-air updates within store rules.
Six questions that make the decision
1. How will people find and use it?
If users discover you through search, links and ads, and use the product occasionally, the web removes the friction of an install. If they use it daily, expect it on their home screen, or search for you in the app store, a store app makes sense.
2. Which device features do you need?
List them honestly. Camera, location and notifications work in all three approaches to varying degrees. Bluetooth devices, background location, health data, NFC payments, widgets, advanced camera processing and AR push you toward native or cross-platform.
3. How demanding is the interface?
Forms, lists, dashboards, bookings and content are well served by any option. Games, real-time video, complex animation and heavy offline data are where native earns its cost.
4. Do you also need a desktop experience?
If your users work at desks, as with many B2B tools, a web app is often the core product, with a mobile app added later for on-the-go tasks.
5. What’s your budget and timeline?
If you need to validate an idea quickly, spending native-app money before you have proven demand is risky. Start lean, learn, then invest where usage justifies it.
6. Who will maintain it?
Think three years ahead. Two native apps need ongoing specialist skills for each platform. A single cross-platform or web codebase is usually easier to staff and keep current.
Our usual recommendations
- Testing a new idea or MVP: web app or PWA, or cross-platform if a store presence is essential.
- Customer app for a business (bookings, loyalty, ordering, accounts): cross-platform, usually React Native or Flutter.
- B2B or internal tool: web app first; add a mobile app for field teams if needed.
- Hardware, media-heavy or performance-critical products: native, or Kotlin Multiplatform for shared logic with native interfaces.
- Content and marketing experiences: web. Almost always.
Common mistakes to avoid
- Choosing native for prestige. Users judge your app by whether it’s fast, clear and reliable, not by the language it’s written in.
- Choosing web to save money, then needing features it can’t support. Check your feature list against the platform before you commit.
- Ignoring the backend. Whichever front end you choose, a well-designed API lets you add other platforms later without starting again.
- Forgetting the app stores. Store review, privacy labels and account deletion requirements all take time; plan for them.
It doesn’t have to be one forever
Many successful products evolve: a web app proves demand, a cross-platform app brings in mobile users, and specific screens are later rebuilt natively where performance matters most. Designing a clean API and shared design system from the start keeps those options open.
Not sure which path fits your product? We’ll review your features, users and budget and give you a straight recommendation. Book a consultation.
Need a hand with this?
Our team designs, builds and secures websites, apps and AI automations for growing businesses.