Native, cross-platform or PWA? How to choose your mobile app approach

The decision in brief

Before any code is written, a mobile project has to settle one question: how many codebases will you maintain, and in what language? There are four broad answers:

Approach	What you build	Typical languages and tools
Native	A separate app for each platform	Swift (iOS), Kotlin (Android)
Cross-platform UI	One app that runs on both platforms	Flutter (Dart), React Native (JavaScript/TypeScript)
Shared logic, native UI	Shared business logic with platform-specific screens, or shared screens too	Kotlin Multiplatform, optionally Compose Multiplatform
Progressive Web App (PWA)	A website that can be installed and work offline	HTML, CSS, JavaScript

None of these is right for every project. The useful way to choose is to go through five factors in order: what the app must do on the device, how it must feel, who will build and maintain it, how long it must live, and which store rules apply.

Native: Swift and Kotlin

Native development means writing the iOS app with Apple’s tools and the Android app with Google’s. On Android, Google describes development as Kotlin-first and recommends starting new apps in Kotlin. Its modern UI toolkit, Jetpack Compose, is Kotlin-only. On iOS, native apps are written in Swift and built with Apple’s Xcode tools.

Where native wins

Day-one access to new platform features. When Apple or Google ships a new API, you can use it directly, without waiting for a framework or plugin to catch up.
Platform look and behaviour by default. System controls, accessibility features and gestures behave exactly as users expect on each platform.
Demanding workloads. Heavy graphics, real-time audio and video, complex background processing, and deep integration with Bluetooth or other hardware are all simplest when nothing sits between your code and the operating system.

The cost

Two codebases, usually two skill sets, and every feature built, tested and released twice. For a small team, that can halve the speed at which features reach users.

Flutter

Flutter takes a distinctive route: it does not use the platform’s own buttons and lists at all. According to its architectural overview, Flutter draws every pixel itself using its own rendering engine, Impeller, which ships inside the app. For release builds, apps are compiled directly to machine code. Platform features are reached through platform channels (message passing to Kotlin or Swift code) or, for C-based APIs, a foreign function interface. Native views such as maps can be embedded using platform views, though the documentation notes these carry overhead.

Strengths: one codebase and one UI that looks identical on both platforms; predictable rendering, since it does not depend on OS widget versions; a fast development loop with hot reload.

Trade-offs: because Flutter re-implements controls rather than using the system’s, matching each platform’s feel takes deliberate effort. Any device capability without an existing plugin means writing native code anyway. Your team also needs to learn Dart.

React Native

React Native lets teams write mobile apps in JavaScript or TypeScript using React. At runtime it creates the corresponding Android and iOS views for each component, so screens use real platform views rather than re-drawn imitations. Its New Architecture, enabled by default for new projects since version 0.76, replaced the old asynchronous “bridge” with the JavaScript Interface (JSI). This lets JavaScript and native code call each other directly. It also adds synchronous layout and support for React’s concurrent features.

Strengths: web teams already fluent in React can contribute quickly; a large ecosystem; native platform controls rather than re-drawn ones.

Trade-offs: you depend on third-party native modules for many device features, and their quality and upkeep vary. Upgrading the framework can mean upgrading many libraries at once. For heavy computation or graphics, work often moves into native modules.

Kotlin Multiplatform

Kotlin Multiplatform (KMP) approaches the problem from the other side: share the parts that do not need to look different, and keep the rest native. JetBrains declared KMP stable in November 2023 with Kotlin 1.9.20. Teams can share as little as one critical module or as much as all the business logic, such as networking, data storage, validation and state, while writing SwiftUI or Jetpack Compose screens. Compose Multiplatform extends this to shared UI, and its iOS support was declared stable in version 1.8.0 in May 2025.

Strengths: you can adopt it gradually inside an existing native app; UI stays fully native if you want it to; Android teams already know the language.

Trade-offs: iOS developers need to work with Kotlin-generated code; the library ecosystem is younger than those of Flutter or React Native; and if you keep native UI, you still build screens twice.

Progressive Web Apps

A PWA is a website built with modern browser capabilities so that it can be installed and run in its own window, and keep working when offline, from a single codebase that also serves ordinary web visitors.

Strengths: one codebase for web, Android and iOS; no store review for updates; instant access from a link; the lowest build and maintenance cost of the four approaches.

Limits to check early:

iOS push notifications for web apps arrived in iOS and iPadOS 16.4, but only after the user adds the web app to their Home Screen, and permission must be requested in response to a user action such as tapping a button.
Device APIs available to web apps are narrower than native ones, and support differs by browser. Check every capability you need on every browser you must support before committing.
Store presence is possible but indirect. Google Play listings can be built with Trusted Web Activities, and packaging tools exist for the Microsoft Store and Apple App Store (web.dev). Apple, however, expects apps to offer more than “a repackaged website” under App Review Guideline 4.2.

Comparing the five factors

1. Device features and performance

List every device capability the app needs: camera, Bluetooth, NFC, background location, health data, payments, widgets, wearables. For each one, check whether your chosen framework supports it today and who maintains that support. If several critical features need custom native code, a cross-platform layer adds work rather than saving it. Equally, for a forms-and-lists business app, any of the cross-platform options can deliver a smooth experience.

On performance, avoid generalisations and test the riskiest screen: build a small prototype of your most demanding interaction on a mid-range Android phone. That tells you more than any benchmark.

2. Team and skills

The best technical option is the one your team can maintain. A company with strong React web developers will move faster with React Native or a PWA. One with Android engineers is well placed for Kotlin Multiplatform. A team with nobody committed to mobile long term should weigh how easy it will be to hire for Dart, Kotlin, Swift or JavaScript in its own market.

3. Maintenance over the app’s life

Every approach carries a yearly upgrade burden, because the stores keep raising the minimum toolchain:

Since 28 April 2026, apps uploaded to App Store Connect must be built with Xcode 26 or later using the iOS 26 (or equivalent) SDK. Since 9 September 2026, iOS and iPadOS apps must target iOS 13 or later.
From 31 August 2026, new apps and updates on Google Play must target Android 16 (API level 36) or higher, with an extension available to 1 November 2026 on request. Existing apps that fall behind become unavailable to new users on newer Android versions.

Native apps absorb these changes directly. Cross-platform apps also need the framework, and every plugin they use, to support the new SDKs, which adds a dependency on other people’s release schedules. Budget for an upgrade cycle every year whatever you choose.

4. Store rules

Some App Store rules affect architecture, not just content:

Guideline 2.5.2: apps must be self-contained and may not download or execute code that introduces or changes features. Keep this in mind for any plan to change app behaviour without a store update.
Guideline 2.5.6: apps that browse the web must use WebKit, although Apple offers entitlements for alternative browser engines in the EU and Japan.
Guideline 4.7: apps may host HTML5 and JavaScript mini apps and mini games, but the developer is responsible for that content meeting the guidelines.
Guidelines 4.2 and 4.2.2: apps need enough native features to rise above a repackaged website, and should not be primarily marketing material or web clippings.

All four are in Apple’s App Review Guidelines. Read them alongside Google Play’s policies before choosing a thin wrapper or remote-update strategy.

5. Time to market and budget

One codebase usually reaches both stores faster and costs less to change. Two native codebases cost more but remove a layer of risk for apps where the platform experience is the product.

A quick decision guide

Choose native when the app depends on the newest platform features, heavy graphics, real-time media or deep hardware integration, or when you have, or will hire, dedicated iOS and Android engineers.
Choose Flutter when you want one team, one codebase and a consistent custom design on both platforms, and your device needs are well covered by existing plugins.
Choose React Native when your team already works in React and TypeScript, and you value native UI components and shared skills with your website.
Choose Kotlin Multiplatform when you already have, or want, native UIs but are tired of writing business logic twice, or when you want to share code gradually inside an existing app.
Choose a PWA when the app is mainly content, forms or transactions, reach and low cost matter more than store presence, and your device needs are covered by the browser.

Whatever you choose, prove the riskiest feature first, write down the reasons for the decision, and plan for the yearly platform upgrade cycle from day one.

Sources

Facts in this article were checked against the linked sources on 9 October 2026. Rules, prices and standards change; check the source before relying on a detail. This article is general information, not legal or financial advice.