Flutter or React Native: how we choose for a client project

What they have in common

Both are open source and mature. Flutter comes from Google and is written in Dart. React Native comes from Meta and is written in JavaScript or TypeScript. Both let one team ship to the App Store and Google Play from shared code, and both are used in large production apps.

For a typical business app, either can do the job well. The differences show up at the edges.

When we lean towards Flutter

Flutter draws every pixel itself, so the app looks the same on every phone. That makes it a strong choice when the design is custom and brand heavy, with its own components and animation, and you want it identical on both platforms. It also holds up well for interfaces with a lot of motion.

When we lean towards React Native

React Native uses the platform's own interface components and shares its language with the web. If your product already has a React web app, or your in house developers know JavaScript, the same people can work across web and mobile and reuse logic between them.

That matters a great deal once we hand over and your own team takes on the code.

The questions that settle it

The framework matters less than the fit. These are the things we ask:

• Who will maintain the app in two years, and what do they already know?
• Is there an existing web app to share code with?
• How custom is the design, and must it match exactly on both platforms?
• Does it rely on device features such as Bluetooth, background location or camera processing?
• How soon does the first version need to reach the stores?

Device features deserve a careful look. Both frameworks reach them through plugins, and the quality of the one plugin you need can decide the question on its own.

A note on performance

People often ask which one is faster. For forms, lists, maps and the other things most business apps are made of, users will not notice a difference.

Performance problems in real apps usually come from how the app is built: too much loaded at once, images that are too large, slow calls to the server. Good engineering matters more than the name of the framework.

Good engineering matters more than the name of the framework.

What stays the same either way

Whichever you choose, some work is identical. You still need a backend for accounts and data. You still need to design for small screens and for people using one thumb.

You still go through App Store and Google Play review, with their own rules on privacy and payments. And you still need to test on real phones, not only on a simulator. The framework is one decision among many.

When neither is right

Some apps should be fully native: games, apps built around a brand new platform feature, or anything that pushes the hardware hard.

And some ideas do not need an app at all. A responsive web app is cheaper to build, needs no store approval and can be found through search. We say so when that is the case.