A Vietnamese fintech startup came to us eighteen months into a React Native project with a problem we see more often than we should: the app worked fine in development, shipped cleanly at launch, and then slowly became a maintenance burden. Minor upgrades broke native modules. The JavaScript bridge started stuttering on the transaction history screen once the list exceeded three hundred items. The team had spent the last two sprints not shipping features but untangling a dependency conflict between a third-party camera library and a React Native version they needed for an Expo SDK upgrade.
The founder asked us the same question every founder in that situation eventually asks: "Would we be better off rewriting in Flutter?"
The honest answer is: sometimes yes, sometimes no, and the decision depends on factors you should have evaluated before the first line of code. This post is what we tell founders when they ask about React Native — not the sales version, the production version.
What React Native actually costs to maintain
When we take on a react native consulting engagement on an existing codebase, the first thing we audit is not the code quality. It is the dependency tree.
React Native's ecosystem is built on npm, which means you get access to an enormous library of packages. That breadth is genuinely valuable. It also means your app's long-term health is tied to the maintenance posture of libraries you did not write and cannot fully control.
The pattern we see repeatedly: a React Native app ships at version 0.70, stable and performant. Eighteen months later, the team needs to upgrade to 0.73 because Expo dropped support for the older version. The upgrade hits a native module — usually something wrapping a camera, biometric auth, or a payment SDK — that has not been updated in four months. You either wait for the library author to update, fork it yourself, or find an alternative. None of those paths is free.
We budget 2–4 weeks per major React Native version upgrade for any app with more than five or six third-party native dependencies. Most teams do not budget this. They discover the cost mid-sprint when they needed the upgrade to unlock something else.
The comparable maintenance story for Flutter is different, not easier. Dart's pub.dev ecosystem is smaller, which means fewer packages but also fewer abandoned packages. The Dart team is more deliberate about breaking changes. Flutter upgrades are rarely painless, but the breakage is more predictable.
The JavaScript bridge: when it actually matters
The historical critique of React Native — that the JavaScript bridge is a performance bottleneck — has become partially outdated. The New Architecture (JSI for the JavaScript interface, Fabric for the rendering layer, TurboModules for native modules) eliminates the asynchronous bridge that caused much of the original latency. For apps adopting the New Architecture and using libraries that have migrated to it, the gap between React Native and Flutter on real devices has narrowed substantially.
But "partially outdated" is not the same as "solved," and the nuance matters.
For content apps, e-commerce, and transactional B2B SaaS — which describes the majority of mobile products we work on — React Native performance on the New Architecture is fine. A well-built React Native app in this category will not have users complaining about frame rates.
The ceiling shows up in three specific scenarios we have hit in production:
Long lists with real-time data updates. A financial dashboard showing a live feed of transactions, or a marketplace showing real-time inventory across hundreds of products, will stress React Native's reconciliation logic in ways a static list will not. FlatList with getItemLayout, windowSize, and proper keyExtractor handles this better than a naive implementation, but it requires discipline across the entire team. Flutter's widget recycling and Dart's ahead-of-time compilation handle this pattern more forgivingly.
Complex gesture-driven animations. If your product's differentiator is motion — transitions, drag-and-drop reordering, physics-based interactions — React Native Animated and Reanimated 2 get you very far, but Flutter's animation framework is more expressive and more predictable. We had a client building an interactive onboarding flow with gesture-triggered state transitions; React Native Reanimated required significant tuning to hit 60 fps on mid-range Android devices. The same logic in Flutter hit 60 fps on the first implementation.
Heavy image processing at the UI layer. Filters, real-time camera overlays, anything doing per-frame image manipulation. React Native hands this off to native modules, which works, but the architecture adds latency. Flutter's Impeller (the default renderer since Flutter 3.10) handles this more natively.
The practical question for any founder: if your app's primary use case is outside those three scenarios, React Native's performance story is not a reason to avoid it. If your app's differentiator lives inside one of them, factor it into the stack decision before you start.
OTA updates: the genuine advantage
The feature that React Native (via Expo and EAS Update) offers that Flutter still does not match well is over-the-air JavaScript updates. You can push a bug fix or a UI change to all users without going through App Store or Play Store review.
For early-stage products iterating weekly, this is significant. One of our clients — a B2C consumer app in the logistics space — was shipping three to four OTA updates per week during the first six months after launch. They caught and fixed a critical booking flow bug on a Friday afternoon without waiting for an App Store review cycle. That would have cost them a weekend of support tickets and user drop-off under a native or Flutter deployment model.
Two caveats that are important to communicate clearly:
Apple's App Store guidelines restrict OTA updates to JavaScript and assets. You cannot use OTA to ship new native modules, change app entitlements, or make changes that materially alter the app's core functionality. The line is enforced inconsistently, but it is real. Teams that push the boundary get apps rejected or pulled.
The second caveat: OTA update velocity creates technical debt if it becomes a substitute for proper release discipline. We have seen codebases where the JavaScript bundle had drifted significantly from what the App Store build described, making version tracking difficult and making it hard to reproduce user-reported bugs reliably. OTA is a tool, not a workflow replacement.
The hiring and team continuity question
One factor that does not appear in technical benchmarks but comes up in every react native consulting conversation we have with founders building for the long term: hire-ability.
React Native is JavaScript and React. Your web team's senior React engineers can contribute to the mobile codebase within days, not weeks. When a mobile engineer leaves, the replacement pool is global. When you need to scale the mobile team quickly, the ramp time is short.
Flutter requires Dart, which is a mid-popularity language with no transferable context outside Flutter. Senior Flutter engineers in Vietnam and across Southeast Asia are more available now than they were three years ago, and the quality is high — we have Flutter engineers on our team we would put against any React Native team. But the pool is smaller. In a tight hiring market, React Native's JavaScript ecosystem is a real structural advantage.
If you are building a product you expect to maintain and scale for five or more years with a team that will turn over, React Native's hire-ability story is one of its strongest arguments.
When we recommend Flutter instead
Despite being honest about React Native's strengths, there are client situations where we recommend Flutter or Flutter native over React Native, and we say so clearly.
If the product has a custom design language that does not map to standard platform UI components, Flutter's pixel-perfect rendering across iOS and Android is worth the ecosystem trade-off. React Native's components render closer to native platform conventions, which is often a feature — but when a client has a bespoke design system, platform-native rendering becomes a liability.
If the product spans mobile, web, and desktop with a shared codebase requirement, Flutter handles this better. One Dart codebase compiling to iOS, Android, web, and macOS or Windows is a realistic production architecture. React Native's web story (via React Native Web) works but is meaningfully more effort.
If the team we are inheriting has no JavaScript background and strong Dart or general compiled-language experience, switching them onto Flutter is more productive than fighting the mental model mismatch.
And if the product needs consistent sub-16ms frame times under load — a trading terminal, an AR experience, a video editor — we will recommend Flutter native or native Swift/Kotlin before React Native, regardless of the team's background.
How we approach this conversation with every new client
The first conversation we have with a founder considering React Native is not about the framework. It is about what the app needs to do in year one versus year three, and who is going to be maintaining it.
We ask four questions:
What is the most performance-sensitive screen in the app, and what does it need to do? If the answer is a list of transactions or a profile page, React Native is fine. If the answer is a live camera filter or a 60 fps gesture-based UI, we need to talk about Flutter.
What does your current engineering team know well? Not as a hard constraint — we can staff any stack — but as a cost factor. Switching a React team onto Flutter is a two to three month productivity tax.
How often do you expect to iterate post-launch, and do you need to push fixes without going through App Store review? If yes, React Native with Expo is the strongest answer on the market right now.
What is your three-year plan for the mobile team — growing it in-house, keeping it contracted, or planning a potential sale or fundraise that includes the codebase? Hire-ability and codebase legibility matter differently depending on the answer.
The framework choice is a cost decision, not a prestige decision. React Native is not better than Flutter. Flutter is not better than React Native. Each is the right answer for a specific set of constraints. Getting those constraints on the table before the first sprint is the difference between a codebase that serves you and one you end up paying to rewrite.
If you are at the point of choosing a stack and want a second opinion grounded in production experience rather than framework preference, reach out through the mobile app development page. The assessment takes about thirty minutes and usually surfaces the deciding factor quickly.
