React Native, Flutter or native: choosing how to build your app

The three options

• Native. Two separate apps, written in Swift for iOS and Kotlin for Android, using each platform's own tools.
• React Native. One codebase in JavaScript or TypeScript that drives the platform's own interface components.
• Flutter. One codebase in Dart that draws the whole interface itself, with its own rendering engine.

React Native and Flutter are both called cross-platform: you write most of the app once and ship it to both stores.

What cross-platform does well

Most business apps are screens, forms, lists, accounts, payments and notifications, talking to a server. Cross-platform frameworks handle this well, and both can reach the camera, location, biometrics, push notifications and offline storage.

The benefit is straightforward. One team builds one app, features reach both platforms together, and a fix is made once. For a first version, or for an app whose value is in the service behind it, that is usually the right trade.

When native is the better choice

• Graphics-heavy apps and games, or anything processing audio and video in real time.
• Deep use of platform features such as home-screen widgets, watch apps, car interfaces or background processing.
• Apps that must adopt new operating-system features the day they are released.
• Cases where one platform matters far more than the other, so there is little to share.

Native is not better in general. It costs two builds and two sets of skills, and it is worth that when the app depends on what only the platform's own tools do best.

React Native or Flutter?

Both are mature and both are used in large production apps. The honest differences are these.

• React Native shares a language and many skills with React on the web. If you have a web team, or a web product in React, that is a real saving.
• React Native uses the platform's own components, so an app tends to look and behave like the phone it is on by default.
• Flutter draws everything itself, so a custom-designed interface looks the same on every device, which suits strongly branded apps.
• Flutter uses Dart, a separate language to hire for and to maintain.

If nothing else decides it, choose the one your developers, or the people who will maintain the app, already know.

What matters more than the framework

Apps rarely fail because of the framework. They fail on the parts around it.

• The backend. Most of an app's behaviour lives on the server: accounts, data, payments, notifications.
• Offline behaviour. What the app does with no signal has to be designed, not left to chance.
• Releases. Automated builds and testing are what let you ship a fix in a day and not a week.
• Crash reporting. You want to learn about a problem from your tools, not from store reviews.
• Store review. Both stores have rules, and submission takes preparation.

How to decide

• List what the app must do on the device itself. If it is mostly screens and data, go cross-platform.
• Check for anything on the native list above. One hard requirement there can decide it.
• Look at who will maintain the app in two years, and choose what they can work in.
• Ask how the backend, releases and monitoring will be handled before you compare frameworks.

A decision made this way is usually quick, and it is easy to explain to the people paying for it.