Flutter vs React Native: choosing a cross-platform stack

Cross-platform frameworks let one team ship to iOS and Android from a single codebase. The two leaders — Flutter and React Native — are both mature, both used in large production apps, and both capable of excellent results.

That makes the decision harder, not easier. Benchmarks rarely settle it. What usually does is your team, your design and your product roadmap. This guide walks through how each framework works, where each shines, and the questions we ask clients before recommending one.

#How each one works

The biggest difference between the two is how they put pixels on screen.

Flutter draws every pixel itself using its own rendering engine, and you write it in Dart. A button in Flutter is not an iOS or Android button; it's a widget Flutter paints. That's why Flutter apps look identical on every device.

React Native maps your components to real native platform views, and you write it in TypeScript or JavaScript. A <Text> component becomes a native text view, so apps feel at home on each platform by default.

// Flutter: a simple stateless widget
class Greeting extends StatelessWidget {
  const Greeting({super.key});

  @override
  Widget build(BuildContext context) => const Text('Hello, world');
}

// React Native: the same component
import { Text } from "react-native";

export function Greeting() {
  return <Text>Hello, world</Text>;
}

Both offer fast refresh during development, so changes appear on a running device in about a second. Both compile to real apps that go through the normal App Store and Google Play review.

#Side-by-side comparison

Neither column is "better". Each row matters more or less depending on your product.

#Performance in practice

Performance debates tend to focus on extremes. For the kinds of apps most businesses build (forms, lists, maps, media, dashboards, checkout flows) both frameworks are fast enough that users won't notice a difference.

Where differences do appear:

• Heavy animation and custom drawing. Flutter's rendering model makes complex, synchronised animation straightforward and consistent across devices.
• Very long, complex lists. Both handle them well with the right components; poor implementation matters far more than the framework.
• App start-up time. Both are competitive. Large bundles, too many plugins and blocking network calls at launch are the usual culprits.
• Low-end Android devices. Test early on a cheap phone, whichever framework you choose. It's where performance problems show up first.

React Native's new architecture removed much of the overhead that used to sit between JavaScript and native code. Flutter's newer rendering engine reduced the jank that some developers saw on first-run animations. Old benchmarks comparing the two are often out of date.

#Design: custom brand or native feel?

This is often the deciding question.

If your product has a strong, custom visual identity (bespoke components, brand typography, distinctive motion) and it must look the same on every device, Flutter makes that easy. You design once and it renders the same everywhere.

If your product should feel like a native app on each platform, following iOS and Android conventions for navigation, controls and gestures, React Native gives you that by default because it uses native views.

Both can do the other approach. It just takes more deliberate effort.

#Your team and hiring

The framework you choose shapes who you can hire and how fast they're productive.

• If your web product is built in React, React Native lets the same engineers contribute to mobile, share types and validation logic, and use familiar tools. That's a real, ongoing saving.
• If you're building a mobile-first product from scratch, Flutter's single, consistent toolkit is quick to learn. Dart is easy for developers who know TypeScript, Java or Kotlin.
• If an agency builds the first version and your team takes over later, choose the framework your future team is most likely to know.

The best framework is the one your team can maintain confidently two years from now.

#Ecosystem and native features

Most apps need some device features: camera, location, notifications, biometrics, payments, file access, background tasks.

Both ecosystems cover the common cases well. The questions to ask are:

1. Is there a well-maintained package for each feature we need? Check recent releases, open issues and whether major platform updates are supported.
2. What happens when there isn't? Both frameworks let you write native code (Swift/Kotlin) and call it from your app. Budget time for this if your product relies on unusual hardware or SDKs.
3. Does a critical third-party SDK officially support the framework? Payment, identity and analytics providers often publish official packages for one or both. An official SDK is a strong reason to lean one way.

#The work no framework removes

Cross-platform frameworks remove most duplication, but some platform work always remains:

• Push notifications need separate setup for Apple and Google services.
• In-app purchases and subscriptions follow each store's rules and review process.
• Permissions (camera, location, tracking) have platform-specific prompts and policies.
• Store listings, signing and releases are separate pipelines for each store.
• Accessibility must be tested with VoiceOver on iOS and TalkBack on Android.

A realistic plan budgets for these from the start rather than discovering them in the last sprint.

#Long-term maintenance

An app is never finished. Each year brings new iOS and Android versions, new device sizes, deprecated APIs and updated store requirements.

To keep maintenance manageable on either framework:

• keep dependencies few and well-chosen
• update the framework regularly rather than skipping versions
• run automated tests on every change
• keep business rules on the server where possible, so app updates are smaller and less frequent

#Our decision checklist

When a client asks which framework to use, we work through these questions:

1. Does a React web codebase or React team already exist? → leans React Native
2. Is the UI highly custom, animated or brand-led? → leans Flutter
3. Do we need desktop or app-like web from the same codebase? → leans Flutter
4. Do critical SDKs officially support only one framework? → follow the SDK
5. Who will maintain the app in two years, and what do they know? → often the deciding factor

#Our default

For most new client products we start with Flutter: it gives small teams a consistent, high-quality result on every device, and it's how we're building our Flutter MFA authentication plugin. When a client's team is React-first, React Native is the better long-term fit and we're happy to build with it.

Not sure which fits your product? Tell us about it and we'll give you a straight recommendation. You can also read more about our custom software and mobile app work.