Why We Chose Flutter Over React Native After Shipping Apps in Both

We shipped our first React Native app in 2019. Our first Flutter app in 2021. By 2023, we'd moved entirely to Flutter for new projects. This wasn't a trend-following decision—it came from watching both frameworks perform in production across 12 different apps.

The short answer: Flutter gave us more predictable outcomes. The longer answer involves hot reload that actually works, widgets that behave the same everywhere, and performance we could reason about. But React Native still wins in specific scenarios, and we'll cover those too.

The Hot Reload Difference Is Real

Every cross-platform framework promises hot reload. In practice, the experience varies dramatically.

React Native's fast refresh works well for simple UI changes. Change a text color, see it update. But the moment you touch navigation state, context providers, or anything involving native modules, you're back to full rebuilds. We tracked this on one project: developers were doing full rebuilds 40% of the time despite "hot reload" being available.

Flutter's hot reload preserves state more reliably. We've changed business logic mid-flow and watched the app continue from exactly where it was. It's not magic—there are still cases where you need a full restart—but they're the exception rather than a regular occurrence.

This matters more than it sounds. On a 6-week MVP timeline, shaving 30 seconds off each iteration cycle adds up to hours per developer per week. At Etere Studio, we've found this single difference accounts for roughly 15-20% faster UI development in Flutter projects.

Widgets vs Native Components: The Predictability Trade-off

React Native renders using actual native components. A button on iOS is a real UIButton. This sounds like an advantage—and sometimes it is—but it creates a fundamental unpredictability.

When iOS 16 shipped with subtle changes to UIButton's touch feedback, our React Native apps inherited those changes automatically. Sometimes that's fine. Sometimes a client calls asking why their app "feels different" after users updated their phones. You're debugging behavior you didn't write.

Flutter draws everything itself using Skia (now Impeller). A Flutter app looks identical on iOS 14 and iOS 17. On a Pixel 3 and a Samsung S23. This pixel-perfect consistency means more design control and fewer "it works on my device" conversations.

The trade-off is real though. Flutter apps don't automatically get new platform conventions. When iOS introduced the new share sheet design, React Native apps got it free. Flutter apps needed explicit updates. For most business apps, we'll take predictability. For apps where feeling "native" matters more than consistency, that calculus changes.

Performance You Can Reason About

React Native's bridge architecture creates a fundamental performance characteristic: JavaScript and native code run in separate threads, communicating through serialized messages. For most apps, this is fine. For apps with heavy animations, frequent native calls, or real-time updates, you hit walls.

We built a fitness app in React Native with real-time heart rate monitoring from a Bluetooth device. The data came in fast—multiple updates per second—and each update crossed the bridge. We spent two weeks optimizing, batching updates, reducing re-renders. Got it working, but it was fragile. One careless setState in the wrong place and the UI would stutter.

Flutter compiles to native ARM code. No bridge. When we rebuilt similar functionality in Flutter, performance optimization was straightforward: profile, find the slow widget, fix it. The mental model matched reality.

This doesn't mean Flutter is always faster. For typical CRUD apps with standard animations, both frameworks perform well. But when you need to optimize, Flutter's architecture makes the path clearer.

When React Native Still Wins

We haven't abandoned React Native entirely. There are scenarios where it's the better choice:

Existing React web team. If you have senior React developers and need a mobile app fast, the learning curve matters. A React team can be productive in React Native within days. Flutter requires learning Dart and a different paradigm—figure 2-3 weeks to real productivity.

Brownfield integration. Adding features to an existing native app? React Native's architecture makes this smoother. You can embed React Native views in specific screens without rebuilding the whole app. Flutter's add-to-app story has improved but still requires more ceremony.

Web-first with mobile secondary. React Native for Web exists, but the real story here is shared mental models. If your primary product is a React web app and mobile is supplementary, keeping the same paradigm reduces cognitive load.

Specific native module needs. React Native's ecosystem of native modules is larger and more mature. If your app depends heavily on a specific SDK that has a maintained React Native wrapper but no Flutter equivalent, that's a real factor.

What Triggered Our Switch

The decision crystallized on a project in late 2022. We were building a logistics app—nothing exotic, mostly forms and maps and real-time location tracking. Standard startup MVP scope.

Three weeks in, we hit a bug where the map component would occasionally freeze after backgrounding the app on certain Android devices. The debugging process took us through React Native's bridge, the native module's lifecycle handling, and Android's activity management. Four days to find and fix.

The fix itself was simple. The journey to find it wasn't. And we realized we'd had similar experiences on previous projects—not always this severe, but a pattern of debugging across boundaries we didn't fully control.

We finished that project in React Native. The next project, we proposed Flutter. The client didn't care about the framework—they cared about the timeline and the result. We delivered two weeks faster than our estimate.

Making the Choice for Your Project

Choose Flutter when: you want predictable timelines, your team is starting fresh or already knows Dart, you need pixel-perfect design consistency, or you're building something with complex animations or real-time features.

Choose React Native when: your team is already strong in React, you're integrating into an existing native app, you need a specific native SDK with no Flutter equivalent, or you're building alongside a React web application.

Both frameworks ship production apps used by millions. The "wrong" choice isn't fatal—it's a trade-off in development experience and specific capabilities.

At Etere Studio, we've stopped treating this as a religious debate. We recommend Flutter for most new projects because it matches how we work best. But we've helped clients evaluate both, and sometimes React Native is the right call.

Evaluating frameworks for an upcoming project? We're happy to talk through your specific situation. Get in touch