Mobile development: native, React Native or Flutter

Before comparing frameworks, check whether you need an installable app at all. MDN defines a PWA (progressive web app) as an app built with web technologies that runs on many platforms from a single codebase, can be installed on the device, works offline and integrates with the system. If your scenario fits within what the browser can do, a PWA is simpler to ship and update. We covered the business side of this choice — store review, acquisition channels, phasing — in “PWA or mobile app”; here is the engineering angle: what actually changes in code, tooling and team.

Engineering signs that the web will not be enough: the app has to live in the App Store and Google Play; you need APIs the browser does not expose, or exposes with limits on a particular platform; background work matters, as does tight system integration (widgets, sharing, biometrics, platform payments); you need a smooth, complex interface with gestures and animation on low-end devices.

A native app is written in the platform’s main language with the platform’s own tools. For Android that is Kotlin: since 2019 Google has developed the platform Kotlin-first and recommends starting new apps with it, while keeping Java support. The UI is built with Jetpack Compose, which the Android documentation calls the recommended modern toolkit for native UI: you describe the interface, and Compose updates it when the state changes. The IDE is Android Studio.

For iOS it is Swift and SwiftUI — Apple’s declarative framework for all of its platforms, with live previews in Xcode. SwiftUI can be adopted incrementally next to the older UIKit. Xcode is Apple’s toolset for developing, testing and distributing apps, and it runs on a Mac.

A middle ground is Kotlin Multiplatform. Google officially supports it for sharing business logic between Android and iOS, and JetBrains’ Compose Multiplatform lets you share the UI too if you want. It suits a team that already writes Kotlin and wants to stop duplicating logic without giving up native UI.

React Native lets you write a mobile app in JavaScript or TypeScript using the same model as React: components, props, state, hooks. The fundamental difference from the web is that there is no DOM and no HTML. Instead of <div> and <p> you use the View and Text components, and at runtime React Native creates real Android and iOS views for them. It is not a website in a wrapper: the screen shows system UI elements.

Since version 0.76, React Native enables the New Architecture by default: the asynchronous “bridge” between JavaScript and native code is replaced by JSI (JavaScript Interface) — direct calls without serialising data. It also supports the concurrent features of React 18 and later. The documentation is upfront that the New Architecture alone does not guarantee a speed-up: the gain depends on your app’s code.

The React Native team itself recommends starting new apps with a framework, and names Expo first: it provides file-based routing, a standard library of native modules and plugins that change native code without hand-editing the Android and iOS projects. At the time of checking, the current release is Expo SDK 57, built on React Native 0.86 and React 19.2.

Flutter solves the same “one codebase, two platforms” problem differently. Instead of system UI elements it draws everything itself: Flutter has its own Dart implementation of every control, including counterparts of the iOS and Android switches. Rendering is done by a C++ engine with the Impeller renderer, which ships with the app; on iOS Impeller is the only supported renderer, and on Android it is enabled by default from API 29.

The code is written in Dart. During development the app runs in a virtual machine with hot reload — changes appear without a full rebuild and without losing state. For release, Flutter compiles the code directly to machine instructions. Flutter reaches platform APIs through platform channels — a message channel between Dart and native code — or through FFI for C libraries.

Performance is deliberately not reduced to a single number in the table: all three approaches end up running compiled native engine code on the device, and bottlenecks usually lie in the specific app — long lists, heavy images, unnecessary re-renders. Compare a prototype of your heaviest screen on a real mid-range phone rather than generic benchmarks.

However the app is written, the output is a package for Android and a package for iOS, signed with developer keys and reviewed by the stores. The differences between stacks are smaller here than they seem.

Below is the order of questions we use as a starting point. It is not a rule but a way not to miss what matters: a “yes” to an early question usually outweighs all the later ones.

Next on the path: your first app with React Native and Expo — from create-expo-app to a styled screen, then navigation with Expo Router. For Flutter there is a separate lesson on Dart and widgets.