Key takeaways
- Start from cross-platform (Flutter or React Native) if you need both stores and one feature set, and move away from it only for a reason below.
- Native fits apps whose core depends on heavy device work or platform-specific features, or whose users are nearly all on one platform.
- Hybrid (a web app in a native shell) fits content-led apps with a strong mobile website, and a PWA may be enough with no store at all.
- “Hybrid” is often used for anything that isn’t native. A web wrapper and a Flutter app are different products with different limits.
- Decide on the first year’s features and who maintains the app, not just the launch budget.
Most articles on this question list pros and cons for each approach and stop there. That leaves you with the same question you started with. This guide works the other way round: it starts from the traits of your project, such as which device features you need, who your users are, what your budget and timeline are and who will maintain the app, and shows which approach each trait points to.
There are really three approaches, not two. “Hybrid” is often used loosely for anything that isn’t native, but a web app in a wrapper and an app built in Flutter or React Native behave very differently. Treating them as one is the most common reason teams pick the wrong option.
What are native, hybrid and cross-platform apps?
A native app is written separately for each platform, a hybrid app is a web app inside a native shell, and a cross-platform app is one codebase that compiles or renders as a real app on both platforms. Here is what each one means in practice.
- Native: a native Android app is written in Kotlin (or, in older codebases, Java) with Android Studio. A native iOS app is written in Swift (or, in older codebases, Objective-C) with Xcode. Each platform gets its own codebase, built with the tools the platform vendor supports first.
- Hybrid: a web app (HTML, CSS and JavaScript) packaged inside a native shell that shows it in a WebView, the platform’s built-in browser component. Wrappers such as Capacitor (often used with the Ionic framework) or the older Apache Cordova add plugins so the web code can reach the camera, files, notifications and other device features.
- Cross-platform: written once in a framework that produces a real installed app for both Android and iOS. Flutter (Google, in Dart) draws every pixel of the interface with its own rendering engine; React Native (Meta, in JavaScript or TypeScript) turns your components into the platform’s own interface elements. How to choose between the two is its own question, covered in Flutter vs React Native.
A third cross-platform route, Kotlin Multiplatform, shares the business logic in Kotlin and, optionally, the interface with Compose Multiplatform, while each platform can keep its own native interface. It suits teams that already have native Android skills.
The table sets out what you get and what each approach costs you.
Weighing the options?
Tell us what the app must do in its first year and who will run it after launch, and we’ll talk through which approach fits.
How to choose: a decision table by project trait
Start with the trait that matters most to your product, then check the others. The table shows which approach each trait usually points to.
| Project trait | Points to | Why |
|---|---|---|
| The app’s core uses heavy device work: real-time camera or AR, Bluetooth hardware, long background tasks, complex 3D | Native | You need direct, immediate access to platform APIs and full control of performance |
| You need Android and iOS with the same features, and the app is mostly screens, data, payments and notifications | Cross-platform | One codebase covers both, and these features are well supported in Flutter and React Native |
| Nearly all your users are on one platform | Native for that platform | One codebase either way, so you get native benefits at no extra cost |
| The app is mostly content (articles, catalogues, forms) and you already have a strong mobile website | Hybrid, or a PWA | You reuse what exists, and the interface demands are modest |
| A tight budget and a fixed launch date for both stores | Cross-platform | One build, one test cycle and one release process |
| Your team already writes React for the web | React Native | Skills and some code (logic, types, API clients) carry over |
| You want the same custom-designed interface on both platforms | Flutter | It draws its own interface, so a bespoke design looks identical everywhere |
| The app must work offline for long periods with large local data | Native or cross-platform | Both handle local databases and sync well; a web wrapper is the weakest here |
| Platform-specific extras matter: home-screen widgets, watch apps, health data, car integrations | Native, or cross-platform with native modules | These features are built with each platform’s own tools |
Two traits deserve a closer look before you decide.
Device features. List every device feature the app needs in its first year, not just at launch. Camera, location, push notifications, biometrics, payments and maps are routine in every approach. Background location, Bluetooth peripherals, on-device machine learning and watch companions are where native work starts to pay off.
Who maintains it. The app you launch is the smallest it will ever be. Ask who will fix bugs and ship updates in two years, and what they know. A cross-platform codebase needs people who know the framework and enough of each platform to debug store and build issues. Two native codebases need two sets of skills, permanently.
If a progressive web app might be enough, with no app store at all, see whether a PWA is enough. In short, a PWA installs from the browser, works offline and can send push notifications, but on iOS push only works once the user adds it to the home screen (iOS 16.4 and later), and it never appears in the store’s search results.
What changes after launch: maintenance by approach
Maintenance is where the approaches differ most, and it is the part most budgets underestimate. Every approach needs yearly work to keep up with new OS versions and store rules.
For what framework upgrades look like in Flutter and React Native apps, read Flutter vs React Native, which covers what each costs to maintain. Whatever you choose, the backend, APIs and admin panel stay the same. That is often half the work of an app, and it doesn’t change with the front-end decision.
The questions we’d ask before choosing
When a client asks should my app be native or cross-platform, we’d answer with questions before recommending anything. Answer the six below for your own app first: each one you can’t answer yet is the next thing to find out.
If the answers point to one codebase, the next decision is the framework. Our pages on Flutter app development and React Native cover how each one is built and when each fits.
Tailwebs builds native Android and iOS apps, and cross-platform apps in Flutter and React Native.
We also publish our own apps on Google Play and the App Store under TailApps, Tailwebs’ product vertical.
Common mistakes when choosing
Five mistakes come up again and again, and each one is cheaper to avoid than to fix.