React Native or Flutter: how we actually choose

Our bias, before anything else: React Native is where our depth is. That is what we have shipped most, and it is what we reach for by default. Flutter is in our stack, we are open to projects built on it, and we are not going to claim years of it that we do not have.

We are telling you that first because most comparisons of these two are written by teams who only do one of them, and it takes about four paragraphs to work out which. Knowing where the writer stands should not be detective work.

With that said, this is a real decision with real trade-offs, and the honest version is more useful to you than a defence of whichever one we happen to prefer.

The one difference that drives everything else

React Native uses the platform’s own interface components. When you put a button on screen, iOS draws an iOS button and Android draws an Android one.

Flutter draws everything itself. It ships its own rendering engine and paints every pixel, so a button is a button because Flutter decided what one looks like, not because the operating system did.

Almost every practical difference between the two comes out of that one choice, and it cuts both ways. Using the platform’s components means you inherit the platform’s behaviour, its accessibility support and its updates for free — and it means the two platforms will never be pixel-identical, because they were never meant to be. Drawing your own means total control and perfect consistency — and it means you own everything you drew, including the parts the platform would have handled.

Where React Native has the advantage

You already have a web team

This is the single biggest factor and it has nothing to do with the technology. React Native is JavaScript and TypeScript, with React’s model of components and state. If your web product is already React, a meaningful part of your team can read, review and eventually contribute to the mobile codebase. Types, validation logic and utilities can be genuinely shared rather than shared in a diagram.

Flutter is Dart. It is a pleasant language and almost nobody on your team writes it.

Hiring and continuity

Follow that logic past the first release. In two years you will need to hire someone, or bring the work in house, or hand it to a different agency. There are far more JavaScript and React developers in the world than Dart developers, and that gap is not closing quickly.

This matters more than it sounds like it should. The most expensive moment in an app’s life is the one where nobody available can safely change it.

Talking to things that already exist

Most mobile work has to reach something outside itself — a payment SDK, a mapping library, a device integration, a piece of native code from a previous build. Both frameworks can bridge to native code. React Native’s ecosystem of ready-made bridges is larger, which in practice means fewer weeks spent writing a bridge that already exists somewhere else.

Where Flutter has the advantage

The design is unusual and the design is the point

If your product’s interface is heavily custom — bespoke controls, distinctive motion, a visual identity that is the reason people use it — Flutter’s approach stops being a compromise and starts being the right tool. You are going to override the platform’s components anyway. Flutter lets you build what you actually want instead of fighting a widget into a shape it resists.

You need the two platforms to be identical

Some products need this. Regulated flows where the screens are part of a signed-off process, training and support material that must match what the user sees, brand systems with no tolerance for variance. Flutter gives you that by default. React Native gets there with effort, and only on the parts you specifically pushed.

Reach beyond phones

Flutter targets desktop and embedded from the same codebase. If the roadmap genuinely includes those — not as an aspiration, as a funded plan — that is worth weighing.

Where the difference does not matter

This section is longer than most comparisons admit.

For a large share of business applications — lists, forms, media, authentication, network calls, local storage, push notifications — either framework will do the job and a user will never be able to tell which one you chose. Performance is not the deciding factor. If you are comparing benchmark numbers, you are almost certainly optimising something your users do not experience.

What decides whether the app is good is what sits underneath it: whether the data layer was designed or bolted on, whether it works when the connection drops, whether errors are handled or merely logged, whether anyone tested it on a five year old handset. Those questions are framework-neutral, and they matter far more than this decision does.

The questions we actually ask

When a client asks us which one, this is the order we go through it in.

1. What does your existing team write? If the answer is React, the decision is usually made on that alone.
2. Who maintains this in two years? If that is likely to be someone you have not hired yet, hiring pool is a real engineering constraint, not an HR one.
3. Is the interface conventional or is it the product? Conventional pushes towards React Native. Distinctive and heavily custom pushes towards Flutter.
4. Does anything require the two platforms to be identical? If yes, that is a strong pull towards Flutter.
5. What does it need to talk to? If there is an SDK or a piece of native code in the picture, check that the bridge exists before committing to either.

Most projects settle on question one or two. If yours reaches question five and the answer is still unclear, the decision genuinely does not matter much, and you should pick the one your team can maintain.

Where that leaves us

We build in React Native. It fits the products we work on, most of our clients have React somewhere already, and the hiring argument has proved right more than once when a project changed hands.

We keep Flutter in the stack because the cases above are real, and because a team that only has one answer will give you that answer regardless of the question. If your product is one where Flutter is clearly the better fit, we will say so during scoping — including if that means telling you we are not the deepest Flutter team you could hire.

What we will not do is tell you the choice matters more than it does in order to make the conversation sound sophisticated. For most products this is the third or fourth most important decision in the project, and the ones above it are about architecture, not framework.

If you are weighing this up

Tell us what you are building and what your team looks like today. We will tell you which way we would go and why, with a rough estimate, before anyone signs anything.

Related reading

• Why we stopped building native apps — the decision one level up
• Mobile App Development — what we build and how