Flutter vs React Native vs native: how we actually choose

Every mobile project starts with someone asking which framework we will use, and the honest answer is that the framework is the last decision, not the first. The product decides it. Here is the framework we use to get there, and what each option genuinely costs you.

Start with three questions, not with a framework

1. What hardware does the app touch? Camera preview with custom processing, Bluetooth Low Energy, NFC, ARKit/ARCore, background location, health sensors, custom audio pipelines. The more the app lives against the metal, the more native pulls ahead. A CRUD app that talks to an API touches nothing special, and cross-platform wins easily.

2. How custom is the interface? A standard app of lists, forms, tabs and detail screens is a solved problem in any framework. An app whose identity is its interface — heavy animation, gesture-driven canvases, a game-like feel — is where you start fighting the abstraction layer.

3. Who maintains it in two years? One codebase maintained by two developers beats two codebases maintained by two developers, every time. If you are a small team or a startup, this question alone often settles it.

Flutter

Choose it when you want one codebase, a consistent look on both platforms, and a UI with real personality.

Flutter draws every pixel itself rather than wrapping the platform's own controls. That is its great strength and its one real weakness. The strength: what you design is what you get, identically on Android and iOS, with genuinely smooth animation. The weakness: your app does not automatically inherit platform conventions, so an app that feels perfectly at home on Android can feel subtly foreign on iOS unless you put the work in.

Practical notes from our own builds:

• Development speed is excellent once the team knows Dart. Hot reload is not a gimmick — it changes how you work.
• The widget model is unusual at first and then becomes obvious. Expect a slow first fortnight.
• App size starts larger than native. Not a problem for most business apps, worth knowing for markets where download size matters.
• The ecosystem is mature for anything mainstream. For a niche SDK you may be writing a platform channel yourself.

We used Flutter for TenantOne, a rental and PG management app, precisely because it is form-heavy and list-heavy across both platforms with a distinct visual identity. That is Flutter's sweet spot.

React Native

Choose it when your team already writes React, or you want to share real logic with a web app.

React Native renders through the actual platform components, so an app tends to feel native by default. If you have web developers, the ramp-up is short — it is React, with different primitives.

Practical notes:

• Shared code with a web front end is real but always less than the marketing implies. Business logic and API layers share well; UI mostly does not.
• The New Architecture has resolved most of the historic performance complaints around the bridge.
• Dependency management needs more discipline than Flutter. Native modules are where React Native projects get stuck.
• Excellent if you are already in the JavaScript ecosystem. Less compelling if you are not — "we know React" is a strong reason, "React Native is popular" is not.

Fully native (Swift + Kotlin)

Choose it when performance, hardware access or platform integration is the product.

You write two apps. It costs more to build and more to maintain, and in return you get the newest platform features on day one, the best possible performance, and no abstraction between you and the OS.

Native earns its cost when:

• The app is graphics or media heavy — games, video editing, real-time camera work
• It integrates deeply with hardware — BLE devices, wearables, industrial scanners
• It must ship widgets, complications, Live Activities, App Clips or deep Siri/Assistant integration on day one
• Battery and thermal behaviour is a selling point, not a footnote

We built the Webyne support portals as separate Android and iOS builds for exactly this kind of reason — the requirements were platform-specific enough that one codebase would have been a compromise on both sides.

The honest trade-off table

What we advise most clients

For the overwhelming majority of business apps — bookings, orders, dashboards, field data, content, internal tools — cross-platform is the right call, and the choice between Flutter and React Native usually comes down to which language your future maintainer will be comfortable in. Spending 1.8× to get two native codebases for a form-driven app is a poor use of money that would be better spent on the backend, the admin panel, or actually marketing the thing.

Reach for native when you can name the specific platform capability that requires it. "It will be faster" is not a reason on its own; modern cross-platform apps are fast enough that users cannot tell. "We are streaming from three BLE sensors while processing camera frames" is a reason.

The part everyone forgets

The framework argument absorbs all the oxygen, and then the project runs late because of the things nobody discussed: the backend API, the admin panel someone has to use every day, push notification infrastructure, app store review, crash reporting, and who pays for the Apple developer account.

Budget for those. We build the backend, the admin panel and the store submission as part of every app project, because an app without them is a demo, not a product.

Thinking about an app? Tell us what it needs to do through Start a project — we will tell you which approach fits and why, with a fixed price and a timeline, within one business day.