The short answer
Native, cross-platform and web are all legitimate ways to build a mobile product. The question is not which technology is better in the abstract. It is which one fits the people you have, the features you need, and how long you intend to maintain the result.
Most bad outcomes come from choosing on reputation, or on what a previous project used, rather than on those three things.
What you are actually choosing between
Native means building each platform with its own tools: Swift and SwiftUI on iOS, Kotlin and Jetpack Compose on Android. You get two codebases, first-class access to everything the platform offers, and an app that behaves exactly as the platform intends.
Cross-platform means one codebase that produces both apps. The two mainstream choices take different routes. Flutter uses the Dart language and draws its own interface with its own rendering engine, so the app looks the same on both platforms unless you choose otherwise. React Native uses JavaScript or TypeScript with React, and renders real platform views. Both let you drop into native code for anything the framework doesn't cover.
Web or PWA means a web application that runs in the browser and can be added to the home screen. There is one codebase for every device, no store review, and updates reach users immediately. The trade-off is narrower access to device features, and that access differs between iOS and Android.
There are also middle paths, such as sharing business logic across platforms while keeping the interface native. They are worth knowing about, but the three options above cover most decisions.
The six questions that decide it
1. What does your team already know?
This is the most underrated factor. A strong React team will be productive in React Native quickly. A team of experienced iOS and Android developers will be slower, not faster, if you move them to a framework they don't know. A good team with tools they understand beats a mediocre fit with the "right" framework.
2. How much platform-specific capability do you need?
List the features that touch the device and operating system: camera and media processing, background work, home-screen widgets, health data, payments, notifications, Bluetooth and other hardware.
Cross-platform frameworks reach these through plugins, which wrap the native APIs. For common needs such as a camera picker, push notifications or in-app purchases, the plugins are well established. The further you go from common, the more likely you are to write native code yourself. Some surfaces, including home-screen widgets and watch apps, are built with the platform's own tools whichever framework the main app uses.
New operating system features also arrive in the native SDKs first. If being early on new platform capabilities is part of your product, that matters.
3. Is the interface performance-sensitive?
For standard screens such as lists, forms, detail pages and navigation, all the mainstream options can be made to feel smooth. The differences show up at the edges: heavy custom animation, gesture-driven interfaces, live camera or video processing, maps with many moving elements, or very long and complex lists. Native gives you the most headroom and the best profiling tools for these. Cross-platform can handle many of them, but expect more tuning.
A web app is the furthest from the hardware, and it tends to show in gesture handling and scrolling of complex views.
4. How quickly do you need both platforms?
If you need iOS and Android at the same time with one small team, cross-platform is the most direct route. If one platform is enough to prove the idea, building natively for that platform first is perfectly reasonable, and keeps the scope small. Scope is usually what decides how fast you can ship an MVP, more than the framework does.
5. Who maintains it in three years?
Every option has a maintenance bill. Native means two codebases that must be kept in step, feature by feature. Cross-platform means one codebase plus a framework, plus plugins maintained by other people, all of which must keep up with two operating systems. A plugin that stops being maintained becomes your problem. A web app has the lightest release process but depends on what browsers allow.
None of these is free. Choose the bill your team is best placed to pay.
6. Who can you hire?
Hiring depends heavily on where you are and what you pay. Native developers are specialists in one platform. React Native draws on the large pool of web developers who know React. Flutter developers work in a language used for little else, although experienced developers pick it up quickly. Check your own market rather than relying on general claims.
Side by side
| Native | Flutter | React Native | Web / PWA | |
|---|---|---|---|---|
| Languages | Swift, Kotlin | Dart | JavaScript or TypeScript | JavaScript or TypeScript |
| Codebases | Two | One, plus some native code | One, plus some native code | One |
| Platform capabilities | Complete and first to arrive | Through plugins or your own native code | Through plugins or your own native code | Limited, and varies by platform |
| Demanding UI | Most headroom | Good, with tuning | Good, with tuning | Weakest |
| Look and feel | Platform standard by default | Consistent across platforms by default | Platform views by default | Web conventions |
| Time to both platforms | Slowest | Fast | Fast | Fastest |
| Distribution | App stores | App stores | App stores | Browser, no store review |
Choose native when…
- The product's value sits in platform features: health data, widgets, background processing, hardware accessories, advanced camera work.
- The interface is the product and has to feel exactly right, with custom gestures and animation.
- You already have native developers, or you only need one platform for now.
- You want to adopt new operating system features as soon as they appear.
Choose cross-platform when…
- You need both platforms soon and have one team to build them.
- The app is mostly screens, forms, lists and calls to your API, with platform features limited to common ones.
- Your team already knows React, which points to React Native, or is happy to standardise on Flutter.
- You accept writing or commissioning some native code for the parts plugins don't cover.
Choose web or a PWA when…
- Reach matters more than device integration: content, booking, dashboards, internal tools.
- You want to release several times a day without store review.
- Users arrive from links and search, and asking them to install an app first would lose them.
- You are testing demand before committing to an app at all.
Three mistakes to avoid
Choosing for the demo. A framework that produces a prototype quickly is not automatically the one you want to maintain. Ask what the fifth release looks like, not the first.
Assuming one codebase means half the work. You still design for two platforms, test on two sets of devices and meet two sets of store rules. The saving is in building features once, not in everything around them.
Putting business rules in the app. Whatever you choose, keep pricing, permissions and core logic on the server. It makes the app thinner and a future change of framework survivable. This is one of the product decisions that decide whether you scale cleanly.
What to read next
The framework is one decision among several that shape a mobile product. The rest of the mobile architecture series covers the others, including how to add AI to an existing mobile app without slowing it down.