'One Codebase, 3x Faster.' A Real Team's Flutter Pitch Met Six Years of Native Reality.

A mobile lead posted a cry for help on r/swift last week, and I read it with the specific dread of someone who has sat in that exact meeting.

Six years of native code. 100,000+ users. Zero real limitations. And a boss who wants to throw all of it away for Flutter, because “one team, one codebase” sounds like a line item that makes the budget spreadsheet happy.

The pitch, verbatim

Here’s the setup, straight from the original post:

“Our mobile apps are native, built about 6 years ago: Android: Java/Kotlin + XML, iOS: Swift + UIKit, Web: React. 100K+ users. Zero limitations adding features or maintaining these apps over the years.”

His plan for the upcoming revamp was sane and boring in the best way: Android to Kotlin + Compose, iOS to SwiftUI, web stays on React. Modernize in place. Everyone’s already trained on it.

Then the boss showed up with a different plan:

“My boss wants to consolidate to Flutter — one team, one codebase, covering web/Android/iOS. His argument: if I put 6 frontend devs on one Flutter codebase instead of splitting across native platforms, we ship 3x faster.”

And the kicker, the line that made me wince because I’ve heard a version of it aimed at me:

“He thinks I’m biased toward native because it’s my background.”

Maybe. Bias is real and worth checking. But “you’re biased” isn’t a rebuttal to “here’s what actually happens when teams do this” — and the replies delivered exactly that.

The internet has receipts

The top comment, from unpluggedcord, is the kind of reply that gets 200+ upvotes because it names the costs nobody puts in the pitch deck:

“Bad call, you will lose your native talent, you will debug more because now you’re debugging 2 layers instead of 1, and you won’t be able to ship with new features because you have to wait for Flutter to adopt. Your boss wants to throw away years of work and rebuild it… It took you 6 years to have what you have today. How long is that going to take to build into Flutter?”

Then the thread did something I love watching happen online: it produced a historical precedent, unprompted, from someone who lived it.

“I used to work at Xamarin. Don’t let Google do to your company what Microsoft did to all the companies who relied on Xamarin.” — vlatheimpaler

Xamarin to MAUI is not ancient history. It’s a five-year-old cautionary tale about what happens when your cross-platform layer is a business decision made by a company that isn’t yours, and that company’s priorities shift. SelectDevice9868 called the Xamarin-to-MAUI transition “a steaming mess,” and nobody in the thread disagreed. Flutter is Google’s framework. Google’s track record of sunsetting things it built is, generously, mixed.

two_three_five_eigth put the general pattern into one sentence that deserves to be framed:

“I’ve never seen a ‘this sucks, let’s toss and rewrite from the ground up’ not be a dumpster fire… If your first codebase sucked, it means you need to change your process and standards, and then apply the new standard to your current code.”

That’s the actual disease here, and Flutter is just this decade’s cure-that-isn’t. The team doesn’t have a “wrong framework” problem. It has six years of undocumented edge cases, accumulated business logic, and hard-won bug fixes that a rewrite doesn’t preserve — it discards, then makes you rediscover the hard way, one angry support ticket at a time.

The one comment that actually complicates the story

I don’t want to make this thread sound unanimous, because it wasn’t quite, and the disagreement is the interesting part.

codepapi pushed back on the pile-on:

“The biggest difference now… is AI. Asking [an AI coding agent] to map just the UI into Flutter with 80% accuracy can probably be done in a 1-2 weeks. Will it be perfect? No, but it will get you there enough to have the next set of engineers go in and polish.”

This is the honest version of the boss’s argument, and it’s worth taking seriously instead of dunking on it. Coding agents genuinely have compressed the mechanical part of a UI port. If “rewrite the screens” was 80% of the cost of a migration, agentic tools have made a real dent in that 80%.

But unpluggedcord’s reply is the one that actually lands the point:

“That same AI can do the same across all three codebases with much less risk, and you don’t take on a 2nd dependency that makes your app feel like shit.”

That’s the whole debate in two sentences. If a coding agent can port screens fast, it can port them fast in Kotlin and Swift too — you don’t need Flutter to get the speed-up, you were already going to get it. What Flutter actually buys you isn’t agent-assisted velocity. It’s one fewer team to manage and one more framework between your app and the platform APIs your app is supposed to feel native on. Those are real trade-offs. They’re just not the trade-off the boss is describing.

I wrote about this exact confusion — mistaking “I can generate code faster now” for “the hard part of my job got easier” — a few weeks ago in Code Was Never the Hard Part. The typing was never the bottleneck. The judgment about what to build, and what platform behavior to preserve, was. A faster typist in a worse-fitting framework is still working in a worse-fitting framework.

What a shared codebase actually costs you

Here’s what doesn’t show up in the “3x faster” pitch, because it’s not a shipping-speed problem — it’s a ceiling problem.

Every post I’ve written this year about a genuinely platform-specific feature — VoiceOver behavior that SwiftUI gets right by default and a wrapper has to reimplement, or the decision tree for when a feature belongs in a Live Activity versus the Dynamic Island — is a feature a shared Flutter widget tree either can’t reach cleanly or reaches through a plugin somebody else maintains, on somebody else’s timeline. unpluggedcord said it plainly: you’re not removing a layer, you’re adding one, and now you debug both.

caguilar51 offered the compromise worth actually considering — share business logic via Kotlin Multiplatform, keep the UI native on each platform. That’s a real middle path. It’s just not what “consolidate to Flutter” means; it’s closer to what the OP was already planning to do with native UI on top of shared-enough conventions.

Why I stayed native running five apps solo

I don’t have six devs. I have zero, most days — it’s me, plus whatever coding agent I’m arguing with that week. If “one codebase, ship faster” were ever going to win an argument against native, it should have won it against me. ThinkBud, PromptKit, RoleBud, and Invoize are all native SwiftUI, built and maintained by one person, and the reason isn’t nostalgia. It’s the same reason unpluggedcord’s top comment got 200 upvotes: the platform-specific stuff — accessibility, background execution, the small feel-right details — is exactly where a shared abstraction leaks first, and I don’t have a second team to absorb the leak. I wrote about the actual mechanics of running that build pipeline solo in Build Time Optimization for the Solo iOS Developer Running 5+ Apps if you want the receipts instead of the vibes.

The OP isn’t biased for wanting to keep native. He’s pattern-matching correctly on a decision his company already tried to make once — Xamarin, MAUI, the whole graveyard of “write once, run everywhere” promises that turned into “debug everywhere, ship nowhere fast.” AI didn’t change that math. It just made the pitch sound newer.

If your team is weighing this same decision, the course lesson on shipping with AI assistance without losing the native feel is a decent place to start — the goal was never to type less, it was to keep the parts of your app that make it feel like it belongs on the device.

The thread ended, more or less, with ThatWoodworkingDude’s reply to the Xamarin comparison: “nods knowingly because been there, done that.” That’s not bias. That’s a scar.