Native, Flutter, or React Native: How We Actually Decide for Client Projects

Every mobile kickoff call eventually arrives at the same question: should this be native, Flutter, or React Native? The client has usually already read a few comparison articles, and most of those articles compare frameworks in the abstract — benchmark numbers, GitHub stars, hiring pool size — without ever asking what the specific app actually needs to do.

The Question We Actually Ask First

Before touching a framework name, we ask three things: how much of the app depends on hardware or platform-specific APIs, how long the client expects to maintain it after we hand it off, and whether iOS and Android need to ship on the same timeline or can stagger.

Those three answers do most of the deciding for us.

When Native Wins

If the app leans on deep hardware integration — background BLE scanning, custom camera pipelines, ARKit/ARCore, anything where the platform vendor ships new APIs faster than cross-platform bridges can catch up — native still wins, and it's not close. We've watched clients spend more engineering time working around a cross-platform framework's hardware limitations than it would have cost to just write two native codebases.

When Flutter Wins

Flutter earns its place when the UI itself is the differentiator — heavy animation, custom rendering, a design system that needs to look identical down to the pixel on both platforms — because Flutter owns its own rendering pipeline instead of bridging to native UI components. That consistency is also Flutter's tradeoff: it renders its own widgets rather than the platform's, so an app can end up feeling slightly "not quite iOS" or "not quite Android" to users who notice that kind of thing.

When React Native Wins

React Native tends to win when the team already has a strong React/TypeScript bench and the app is more business-logic-heavy than UI-exotic — forms, data views, workflows wrapped around a handful of native modules for camera or push notifications. The ecosystem of maintained native modules is deep enough now that most "does React Native support X" questions have a real answer, not a workaround.

A Practical Example

A logistics client came to us wanting a driver app with live GPS tracking, offline-first order queuing, and a barcode scanner — the kind of feature set that touches hardware constantly. We built it native on both platforms rather than reaching for a cross-platform framework, specifically because background location tracking behaves differently enough between iOS and Android that a shared abstraction layer would have meant debugging platform quirks through an extra layer instead of directly.

Contrast that with a retail client's loyalty app: mostly account views, offers, and a points ledger, with one camera scan feature for receipt upload. React Native was the right call there — the team shipped both platforms from one codebase in a fraction of the time two native builds would have taken, and the one native-module dependency (the camera scanner) was already well-supported.

The Question That Actually Matters More Than the Framework

The framework debate gets more attention than it deserves because it's the visible decision. The quieter decision that shapes a project more is who maintains the app after launch. A client with no in-house mobile engineers is often better served by whichever option minimizes ongoing platform-specific maintenance burden, even if it's not the technically "purest" choice for the feature set.

Our rule of thumb during scoping: if hardware integration is central to the app, start from native and only give it up for a specific, provable reason. If it isn't, start from whichever cross-platform option matches the team's existing skills, and reach for native modules only where the app genuinely needs them.

If you're weighing this decision for an upcoming build, our mobile engineering team scopes projects against exactly these tradeoffs before recommending a stack — not the other way around.