React Native vs Flutter: choosing a mobile stack

React Native vs Flutter is one of the most common questions we hear from founders planning a mobile app. Both frameworks let one team ship to Android and iOS from a single codebase, both are backed by large technology companies, and both power apps used by millions of people. The honest answer is that either can be the right choice. What matters is matching the framework to your team, your product and your long-term maintenance plan, and recognizing the cases where neither is ideal and a native app is the better investment.

Our developers work across all four options: React Native, Flutter, native Android with Kotlin and native iOS with Swift. This article sets out how we decide between them on client projects, in plain business terms first and technical detail second.

The short version#

The rest of this article explains the reasoning behind each row, so you can test it against your own situation rather than taking it on trust.

How React Native works#

React Native lets developers write the app in JavaScript or TypeScript using React, the same component model widely used for web front ends. The framework renders real native UI components on each platform, so a button on iOS is an iOS button and a list on Android is an Android list. With Expo, much of the setup, build and over-the-air update tooling comes ready to use, although over-the-air updates should only carry JavaScript fixes; anything that changes native code or permissions still needs a new store release.

• Shared skills with the web: teams already using React and TypeScript can move between web and mobile with little retraining.
• Shared code with the web: validation schemas, types and API clients can often be reused from a TypeScript web project.
• Native look and feel: because it uses platform components, the app tends to feel at home on each operating system.
• Large ecosystem: many libraries are available for common needs such as navigation, forms and device APIs.

The main caution is dependency management. Third-party native modules vary in quality and maintenance, so it pays to choose libraries carefully and keep upgrades regular rather than letting them pile up.

How Flutter works#

Flutter uses the Dart language and draws every pixel itself with its own rendering engine rather than using platform UI components. That gives designers and developers precise control over how the app looks, and it makes the UI behave identically on both platforms. State management in our Flutter projects always uses Riverpod, which keeps business state predictable and testable.

• Pixel-level control: custom designs, rich animations and branded interfaces are straightforward to build.
• Consistency: the same UI renders the same way on Android and iOS, which simplifies design review.
• Strong tooling: hot reload, a comprehensive widget library and good testing support out of the box.
• Wider targets: the same codebase can extend to web and desktop where that makes sense.

The trade-offs are that Dart is a separate language from your web stack, so less code is shared with a TypeScript web application, and that apps need deliberate work if you want them to follow each platform's native conventions closely.

React Native vs Flutter: side-by-side comparison#

Performance

Performance debates between the two frameworks are often louder than the real-world difference. For forms, lists, dashboards, booking flows and e-commerce screens, both deliver smooth experiences when built properly. Flutter has an edge for heavy custom animation because it controls rendering directly. React Native's newer architecture has reduced the old overhead of communicating between JavaScript and native code. In practice, slow apps are almost always caused by oversized images, unpaginated lists, excessive re-rendering or chatty network calls, and those problems exist in every framework.

Team skills and hiring

If your company already runs a React and TypeScript web product, React Native usually lowers the cost of ownership because the same people can work on both. If you are starting fresh with a design-led consumer product, Flutter's UI control may matter more than skill overlap. Either way, think about who will maintain the app in three years, not only who will build version one.

Long-term maintenance

Mobile apps are never finished. Operating system updates, store policy changes and library upgrades arrive every year. Budget for regular maintenance from the start, keep dependencies current, and use automated tests and continuous delivery so updates are routine rather than risky. Our software maintenance and support work is built around exactly this rhythm.

When to go native with Kotlin or Swift#

Cross-platform frameworks cover most business apps, but not all of them. Native development with Kotlin and Jetpack Compose on Android, or Swift and SwiftUI on iOS, is the better choice in a few clear situations.

• The app targets only one platform, for example an Android app for field staff on company-issued devices.
• It depends heavily on hardware or background capabilities such as Bluetooth peripherals, continuous location, or device management.
• You need the newest operating system features as soon as they are released, before cross-platform libraries support them.
• The app integrates closely with platform features such as widgets, watch apps, car integrations or advanced camera processing.
• Performance requirements are extreme, such as real-time media processing or complex on-device computation.

Native code gives you full access to the platform with no abstraction layer. The cost is that supporting both platforms natively means maintaining two codebases, often with two sets of specialists. For a single-platform app with deep integration, that cost disappears and native is usually the cleanest answer.

What stays the same whichever framework you pick#

The framework is only one part of a mobile stack. The parts that protect your users and your data should be consistent regardless of the choice, and they are where we spend most of our review effort.

• Tokens stored in the platform's secure storage, Keychain on iOS and Keystore on Android, never in plain local storage.
• Short-lived access tokens with rotating refresh tokens for authentication.
• Certificate pinning for apps handling sensitive financial or health data.
• Obfuscated release builds, staged rollouts and crash monitoring from the first release.
• Accessibility, clear offline behaviour and a cold-start target of about two seconds on a mid-range phone, whichever framework renders the screens.
• One versioned REST API shared with the web application, so business rules live on the server and not in each client.

That last point deserves emphasis. When the mobile app and the web app share one backend and one set of validated API contracts, adding a feature means building it once on the server and exposing it to both clients. Our web and backend stack is designed so that mobile clients are first-class consumers of the same API.

A practical way to decide#

1. 1Write down which platforms you must support at launch and within two years.
2. 2List the device features the app depends on, and flag any that are unusual or hardware-specific.
3. 3Describe the design ambition: close to platform conventions, or heavily branded and animated.
4. 4Identify the skills your existing team has and who will maintain the app long term.
5. 5Check whether you have a TypeScript web product whose code and contracts could be shared.
6. 6Build a small proof of concept for the riskiest feature before committing to the full build.

If the answers point to two platforms, conventional UI and a TypeScript web product, React Native is usually the natural fit. If they point to two platforms and an ambitious custom design, Flutter is often stronger. If they point to one platform and deep device integration, go native.

The best mobile framework is the one your team can still maintain confidently three years after launch.

How we help#

Because our developers are trained on all four options within one set of engineering standards, we can recommend a framework without the bias of only knowing one. We start with discovery to understand users, devices and integrations, then design, build in agile increments and support the app through its first months in production. You can read more about our mobile app development approach and the exact libraries we use on our mobile app stack page.

If you are deciding between React Native and Flutter right now, share your requirements through our project enquiry form and we will give you a reasoned recommendation for your specific app.