React Native vs Flutter in 2024: what actually decided it for our last five clients

Framework comparisons usually stay abstract: performance benchmarks, GitHub star counts, hiring pool size. Those things matter, but they rarely decided anything on our last five mobile projects. What actually tipped each decision was much more specific to that client's situation, and looking back across five real engagements is a more useful guide than another feature-by-feature table.

We used to lead these conversations with a general framework recommendation and then fit the client's situation to it. We now do the opposite: gather the client's specific constraints first, then let the framework choice fall out of those constraints, which is the only reason these five projects landed on two different answers instead of us just picking a house favorite and defending it every time.

A logistics startup already had a React web app and a small team comfortable with that ecosystem. React Native let two of their existing engineers contribute to the mobile app without learning a new language, which mattered more than any performance difference. Dart, Flutter's language, would have meant either hiring specifically for it or a slower ramp-up for a team on a tight runway.

Six months after launch, those same two engineers were still actively contributing to the mobile codebase alongside our team, something that almost certainly wouldn't have happened had we recommended Flutter and forced them to learn Dart from scratch on a live project under deadline pressure.

A fitness app with a lot of custom, physics-based animation in its core workout-tracking screen went with Flutter. Flutter's rendering engine draws every pixel itself rather than bridging to native UI components, which made the specific animation work meaningfully smoother and easier to get pixel-perfect across both iOS and Android from one codebase.

We prototyped the same animation sequence in both frameworks before committing, specifically because this client's whole value proposition rested on the workout experience feeling premium and responsive. The Flutter prototype held a consistent frame rate under the same test conditions where the React Native version occasionally stuttered, which settled the decision faster than any general benchmark could have.

A healthcare app needed tight integration with Apple HealthKit and Google Fit, plus some Bluetooth device pairing. React Native's larger ecosystem of native modules for exactly this kind of integration made it the faster path, since Flutter's plugin ecosystem for niche native APIs, while growing, was thinner for this specific combination at the time we scoped it.

We spent a day evaluating available plugins for both frameworks before quoting this project, since guessing wrong here would have meant writing custom native bridge code either way, a meaningfully more expensive path than using an existing, maintained plugin. That day of evaluation upfront saved what would likely have been weeks of custom native development later.

An early-stage marketplace app needed to ship fast on a tight budget with no long-term plan to hire in-house mobile developers immediately after launch. We leaned React Native here too, mainly because JavaScript/TypeScript developers are easier and cheaper to find for a founder hiring their first internal engineer post-launch than Dart developers are, which matters once we hand a codebase off.

We explained this reasoning directly to the founder rather than just stating the recommendation, since it's a decision with real consequences eighteen months down the line, well past the point where we're actively involved, and a founder who understands the tradeoff can make a better call than one just trusting our default.

A field-service app running on lower-end Android devices used by technicians needed to stay fast and responsive on hardware that would choke on a heavier app. Flutter's more predictable performance characteristics on constrained hardware, since it doesn't rely on a JavaScript bridge the way React Native historically has, made it the safer choice here.

We tested the app on the client's actual field hardware, a specific budget Android model already deployed to their technicians, rather than on a modern flagship device, since that's the environment the app actually had to perform in. Flutter's build ran noticeably smoother on that specific hardware, which is the only test result that mattered for this particular decision.

The deciding factor was never "which framework is better." It was always one specific, concrete constraint: existing team skills, animation complexity, native integration needs, post-launch hiring plans, or target hardware. Ask about those four things before asking which framework to use, and the answer usually becomes obvious without needing a benchmark chart at all.

We now ask all five questions in the first scoping call for any mobile project, regardless of how strongly a founder already leans toward one framework, since more than once a founder's initial preference has changed once they saw their own answers laid out against these specific constraints rather than a general opinion about which framework is more popular.

Some founders, understandably tired of weighing frameworks, ask us to simply recommend whichever one we personally prefer. We resist answering that directly, because a house preference applied blindly is exactly how a team ends up with the wrong tool for a specific job. Our actual answer is always the same: give us the five constraints first, and the framework choice will follow from your situation rather than from our institutional habits.

That said, if pressed for a genuine default in the absence of any distinguishing constraint, we lean React Native slightly, mainly for hiring pool depth in most markets we work in. But that's a tiebreaker, not a recommendation, and it only applies once none of the five real questions has produced a clear answer on its own, which in practice is a fairly rare situation once a founder actually works through them.

We also revisit this comparison roughly every year internally, since both ecosystems keep shifting underneath these decisions: React Native's new architecture has closed some of the historical performance gap with Flutter, and Flutter's plugin ecosystem for native integrations has matured considerably since the healthcare project described above. The specific five constraints stay stable as a framework for deciding. The right answer to any one of them, given how fast both platforms are moving, is worth checking again rather than assuming it hasn't changed since the last project.