Should your team rewrite the native app in Flutter? The real answer.

A VP of engineering once asked me, in a hallway, whether his team should rewrite their iOS and Android apps in Flutter to "save fifty percent of headcount." I asked him three questions and his answer changed by the third. The questions were: how senior is the iOS lead, how many platform-specific features ship per quarter, and what is the App Store rating versus the Play Store rating today.

If you are reading this because someone above you wants the same rewrite, this post is the calm version of that hallway conversation. The real costs, the team realities, and a direct recommendation for three team sizes. No "it depends." A specific answer for each.

Context: what the rewrite actually is

A "Flutter rewrite" of two native apps is not a rewrite. It is six things at once:

1. A rewrite of every screen in Dart.
2. A migration of every native integration to a platform channel or a Flutter plugin.
3. A reconstruction of every test suite from scratch.
4. A new build, sign, distribute, and crash-reporting pipeline.
5. A reorganization of the team (some iOS engineers will leave; some new Flutter engineers will need to be hired).
6. A loss of institutional knowledge embedded in the native codebases.

The pitch usually focuses on item 1 and treats items 2 through 6 as "just engineering work." Items 2 through 6 are the entire decision.

Team skill cost

If you have one strong iOS engineer and one strong Android engineer, they are not equivalent to two strong Flutter engineers. Flutter is a different skill. Strong Dart developers who also understand Skia/Impeller, the gesture arena, and platform channels are not as common as the "easy to hire" pitch claims.

A realistic skill plan:

• Train one of your existing native engineers on Flutter. Give them six months of part-time exposure plus a sprint of dedicated work. They will be productive but not senior.
• Hire one experienced Flutter engineer externally. Their salary is comparable to a senior native engineer in your market, not lower.
• Keep at least one native engineer per platform on staff for platform-specific work that does not go away.

Net headcount change after a rewrite: usually zero or a small reduction. Not the 50% the slide deck promised.

Timeline reality

A reasonable, evidence-supported estimate for rewriting a non-trivial production app in Flutter is roughly equal to the original native development time minus the design and product discovery work. If the iOS app took twelve months to build originally, expect eight to twelve months to rewrite it in Flutter, even though "the design is done."

The reasons it does not go faster:

• Every platform-specific feature must be reimplemented through a channel or plugin.
• Every UI detail that was solved in UIKit must be solved again in Flutter.
• Every edge case that took a sprint to fix in the original will take a sprint to find and fix in the rewrite.
• The team building the rewrite is also maintaining the original. Both apps need bug fixes, App Store responses, and feature work for legal or compliance reasons during the migration window.

The "rewrite is faster than original development" claim assumes the rewrite team is building exactly what shipped. Real rewrites change scope. Once people are touching the code, they want to redesign the part they hated.

Feature parity gaps

Some native features are awkward or partial in Flutter. A non-exhaustive list to audit before you commit:

• App Clips on iOS / Instant Apps on Android (limited Flutter support, native shell required).
• Widgets / iOS Home Screen Widgets (must be written in SwiftUI; Flutter only owns the main app).
• Live Activities on iOS (SwiftUI only).
• Apple Watch / Wear OS (separate native apps; cannot be Flutter).
• CarPlay / Android Auto (native frameworks).
• Background audio with the platform's native UI (possible in Flutter but with caveats).
• Some accessibility features (VoiceOver and TalkBack work but with edge cases for custom widgets).
• Deep platform integration: Siri Intents, Shortcuts, App Intents, ShareSheet extensions.

If your roadmap includes any of these, your "Flutter rewrite" still has a substantial native component. The two-codebase reality returns the moment you ship a watch app or a widget.

Maintenance equation, long term

Two native codebases: roughly 1.6x to 1.8x the maintenance cost of one, not 2x. iOS and Android maintenance is largely independent and parallelizable.

One Flutter codebase: roughly 1.2x to 1.4x the maintenance cost of one native, when you account for plugin upgrades, Flutter version upgrades, and platform-specific bugs that still need to be triaged per platform.

Net long-term saving: real, but smaller than the pitch. Order of 25 to 40 percent on engineering maintenance, not 50 percent. And the saving depends on Flutter version upgrades being smooth, which most are but some are not (the migration from Flutter 2 to 3 took weeks for some teams).

The three team sizes

Caption: a decision flowchart shaped by team size and seniority. The smaller the team, the more attractive Flutter is. The larger the team, the worse the rewrite-risk-to-saving ratio.

Team of 1 to 3

If you are this small, Flutter is genuinely useful. One person cannot keep two native codebases at quality for long. Flutter lets one person credibly ship for both platforms, with the platform-feel tax discussed in Flutter on iOS still does not feel native.

Verdict: rewrite is reasonable, especially if your existing engineer wants to learn Flutter. Stay native only if your iOS lead is senior and the product depends on iOS feel.

Team of 4 to 15

Use the add-to-app pattern. Keep the native shells. Build new features as Flutter modules embedded in the existing apps. You get incremental Flutter adoption, no big-bang rewrite, and you can stop at any point.

Verdict: do not rewrite. Add Flutter incrementally. Re-evaluate in a year.

Team of 15+

The math does not work. Two native codebases at this size are well-funded enough that the marginal saving from Flutter is small relative to the migration risk. The teams have specialized; merging them into one Flutter team usually loses senior engineers.

Verdict: keep native. Invest in a shared design system, shared API contracts, and shared release tooling. Those give you most of the consistency wins without the rewrite risk.

What to do this week, regardless

If your leadership is asking the question, do this:

1. Pick one screen in your existing app — not the most complex, not the simplest — and have one engineer build it in Flutter as a standalone module. Two weeks, full time.
2. Run that module on real devices alongside the native screen. Compare scroll feel, animation, perceived snappiness, and rendering on a mid-tier Android.
3. Estimate what every plugin you would need would cost to integrate, including the ones that do not exist yet.
4. Take the result to leadership with numbers, not opinions.

This pilot is the cheapest way to make the decision evidence-based. It costs two weeks. The wrong rewrite costs a year.

What I would do differently

• I would not have agreed to the rewrite scope until the pilot screen shipped to real devices. Talking about feel is useless.
• I would have told leadership "no" the first time someone said "save 50%." That number is not real.
• I would have kept one of the native engineers explicitly on the rewrite team, not as a consultant. The platform knowledge they had was irreplaceable.
• I would have written down the features we would not build in Flutter (Live Activities, widgets, watch app) before starting. We discovered them mid-project and panicked.
• I would have set a "kill date" for the rewrite. If the rewrite is not feature-complete by date X, we ship as-is and reassess. Without a kill date, rewrites become eternal.

Closing opinion

Do not rewrite. Add Flutter incrementally if it makes sense. The full rewrite is the most expensive way to discover the platform-feel tax that anyone with eighteen months of Flutter experience has already discovered. For the engineering-level version of this story, see I have shipped apps in Swift, Kotlin, and Flutter. For the structure to use if you do go ahead, see Structuring a large Flutter codebase. What actually scales.