US | Engineering | 2026-08-16

Flutter vs React Native vs Native: Choosing for a Business App

Three questions settle the framework choice before anyone opens a benchmark, and sometimes the honest answer is two native codebases.

The framework question usually gets settled in the first ten minutes of a kickoff call and reopened fourteen months later, when someone needs a Bluetooth sensor to keep reporting while the phone is locked. All three options can ship the same booking app, the same catalog, the same loyalty program. The decision is not about which technology wins in the abstract. It is about which of your specific constraints one of them handles badly.

Here is a way to make the call on evidence you already have, rather than on whichever developer spoke first.

Three questions that decide it before any benchmark

Who maintains this in eighteen months? This matters more than rendering pipelines. If you have an in-house team writing React and TypeScript, React Native lets those people ship mobile without becoming different engineers, and it lets web and mobile share validation logic, types, and API clients. If you have no engineers and will hire a contractor when something breaks, pick what your local or agency market can staff on short notice. A codebase nobody available can read is expensive no matter how elegant it is.

What does the app need from the device and the OS? Write the list before anyone argues. Camera, photo library, standard location, notifications, biometrics, and payments are solved everywhere. Background Bluetooth, background location with geofencing, CarPlay and Android Auto, watch apps, home screen widgets and Live Activities, HealthKit, App Clips and Instant Apps, and vendor SDKs shipped only as native binaries are where the answer changes.

How custom is the interface? An app built from lists, forms, tabs, and modals is well served by any of the three. An app whose value is a custom canvas, a drawing surface, an animated data view, or heavy branding that must look pixel-identical on both platforms leans toward Flutter, which draws every pixel itself instead of composing platform widgets.

What each one is actually good at

Those size numbers matter in some markets and nowhere else. If you sell where users watch data plans and delete large apps, a 10 MB floor is a real consideration. For a B2B tool on company phones, it is noise.

Where native earns its extra cost

Building twice typically runs 1.5x to 2x a single cross-platform build for the same scope, and roughly doubles the ongoing maintenance surface. Several cases still justify it.

• Sustained background hardware work. Continuous BLE connections, background audio pipelines, VoIP with CallKit, or activity tracking that must survive the OS suspending your process. Cross-platform abstractions leak here first, because the underlying platform behaviors are not analogous to begin with.
• Deep platform surfaces. Watch apps, complications, CarPlay, widgets, Live Activities, Siri and Assistant integration. You write these natively even inside a cross-platform app. The question is whether they are the product or a garnish.
• Vendor SDKs with no bridge. Some banking, healthcare, device management, and hardware vendors ship native-only SDKs and decline to support wrappers. If your integration partner says that, the argument is over.
• Frame-level media work. Real-time camera filters, on-device inference on every video frame, AR. Possible in either framework, but you will be writing native code regardless, so the shell adds coordination without removing work.
• Day-one adoption of new OS features. If your differentiation depends on shipping the week a new system API lands, waiting on plugin support is a business risk.

A hybrid is often the honest answer: Flutter or React Native for the 90% of screens that are lists and forms, with a native module or a native watch companion for the part that genuinely needs it.

The failure modes of cross-platform

The realistic risks are not performance. They are supply chain and upgrade tax.

Plugin abandonment. Your app will depend on somewhere between twelve and thirty community packages. Some are maintained by one person who eventually stops. When an OS release breaks one, you fork it, replace it, or wait. Before committing to any package that touches hardware, payments, or authentication, check the date of its last release and whether more than one person holds commit access.

Upgrade cadence. React Native was historically painful to upgrade, though managed Expo workflows and the New Architecture that became the default in recent versions improved this considerably. Flutter's breaking changes tend to be smaller, but plugin churn moves the same pain into the dependency layer. Native code skips the framework layer and still owes you the annual OS work. Nobody escapes maintenance. The choice determines who you are waiting on.

Debugging across a boundary. When something misbehaves in a bridged layer, you need someone who reads both the framework and the native side. That person costs more than a framework generalist and is harder to find quickly.

Where performance differences actually show up

For standard business apps, all three hold smooth frame rates and users cannot tell them apart. Differences surface in specific places: very long lists with complex cells, image-heavy feeds under memory pressure, rapid gesture-driven animation, cold start on low-end Android hardware, and anything doing meaningful computation on the UI thread. If your app has none of those, framework choice is not a performance decision, and treating it as one burns the discussion on the wrong variable.

Running the decision

1. Write the device and OS feature list first. If a native-only item is central, plan for native code somewhere and decide whether it lives inside a cross-platform shell.
2. Name the maintainer. An existing React team points to React Native. No team plus an agency relationship points to whichever stack that agency and its likely successors staff reliably.
3. Check whether a web app shares logic. If a substantial TypeScript codebase already exists, that shared surface is worth real money across several years.
4. Assess UI ambition. Identical branded pixels across platforms favors Flutter. Interfaces that should feel exactly like each OS favor native views.
5. Only then compare quotes, on identical scope with the same integration list.

Most business apps land on a cross-platform stack because the constraints that argue for two native codebases are simply absent. When those constraints are present, they tend to be specific and obvious in advance, and paying for native up front costs less than discovering the limitation after launch.