Introduction
Is Flutter dying? No. Google shipped a Flutter release this year, Alibaba’s Xianyu app still runs on it at massive scale, and nobody serious is telling founders to rip out a working Flutter codebase for no reason.
But something did change, and pretending otherwise does startups a disservice.
Pedals Up is an AI-native product engineering company that builds web, mobile, and AI products for startups and scale-ups across the US, UK, and UAE, and we get asked some version of “should we still bet on Flutter” almost every quarter now. The honest answer isn’t about widgets or rendering speed. It’s about what happened to Google’s Flutter team in April 2024, and what that quietly told every CTO paying attention
What Actually Happened to Flutter (and What Didn't)
In late April 2024, Google laid off staff from its Flutter, Dart, and Python teams as part of a broader round of “Core” team cuts. A WARN notice filed that month disclosed 50 affected roles across three Sunnyvale offices, and CNBC reported roughly 200 people were let go across Google’s wider Core team cuts that same week (TechCrunch).
Google’s framing was careful. A spokesperson called it “organizational restructuring.” Flutter product lead Kevin Moore told the community directly: “You’re betting on Flutter and Dart. So am I. So is Google.”
Both things are true. Flutter kept shipping releases. The framework did not die. But the team that owns it got smaller right before a developer conference, and that is not a rumor; it’s a filed document.
Here’s the part that matters more than the headline: nothing about Flutter’s rendering engine, its widget tree, or its cross-platform performance changed that week. What changed was risk. And risk is exactly the thing a CTO is paid to notice before it shows up in a postmortem
The Real Reason Smart Teams Are Leaving Isn't Performance
Is Flutter dying in 2026? No. Flutter is actively maintained, still receives regular releases, and still powers large production apps. What’s shifted is confidence in its long-term staffing and governance inside Google, which is a different problem than the framework being broken. Teams leaving Flutter are rarely leaving because it renders badly. They’re leaving because a single-vendor bet on a smaller language got harder to justify to a board once the team behind it visibly shrank.
Most “Flutter vs React Native” content argues about hot reload speed, widget libraries, or benchmark numbers that were stale two release cycles ago. That’s not what’s driving the quiet exits. What’s driving them is a governance question nobody puts in a comparison table: if the team maintaining your core mobile stack gets cut again, who owns your roadmap?
That’s not a Flutter-specific flaw. It’s the tax every team pays for standardizing on a framework owned entirely by one vendor with no external steering committee. Flutter just became the framework where that tax got a receipt.
The Hiring Problem Nobody Puts in the Slide Deck
Here’s the tradeoff that rarely gets said out loud in vendor pitches: Flutter’s single-codebase pitch is real, but it’s built on Dart, and Dart’s hiring pool is genuinely small.
What is the actual hiring risk with choosing Flutter? Dart is used by 5.9% of developers overall and 6.1% of professional developers, compared with 66% and 43.6% for JavaScript and TypeScript and 10.8% for Kotlin, according to the 2025 Stack Overflow Developer Survey (Stack Overflow). That gap doesn’t matter when a team is three engineers. It matters enormously when a Series B startup needs to go from three engineers to twenty in a year and can’t fill half the reqs with people who’ve written production Dart.
This is the part that doesn’t show up in a technical evaluation, because it isn’t technical. It’s an operations problem that shows up eighteen months after the stack decision, when recruiting is the bottleneck instead of code.
Teams that felt this pain didn’t necessarily leave loudly. Most just quietly stopped writing new Flutter modules, hired for React Native or native instead, and let the Flutter surface area shrink over time rather than announcing a rewrite.
Where Flutter Actually Breaks Down Technically
Hiring risk isn’t the only reason teams leave. There’s a real technical ceiling, and it shows up specifically when an app needs tight, low-latency access to native hardware.
What is a platform channel bridge, and why does it matter? A platform channel is Flutter’s mechanism for letting Dart code talk to native iOS or Android APIs. Every call gets serialized into a message, passed across the bridge, and deserialized on the other side. For UI and most app logic, this overhead is invisible. For anything latency-sensitive, like real-time hardware control, it isn’t.
One engineering team building a hardware-integrated industrial application documented this directly: their Bluetooth data round-trip dropped from roughly 150 milliseconds under Flutter to about 5 milliseconds after moving to Kotlin Multiplatform, because the app needed sub-16-millisecond control loops that the bridge simply couldn’t guarantee. They also reported spending 40 percent of their engineering time fighting the cross-platform abstraction layer itself instead of shipping features.
This isn’t Flutter failing at its job. It’s a mismatch: Flutter is optimized for shared UI across platforms and fast iteration on one codebase, and a small number of apps need deterministic, low-latency native access instead. Most consumer and B2B SaaS apps never hit this ceiling. Apps doing real-time hardware control, AR, or heavy native SDK integration hit it fast.
Where Flutter Still Wins
None of this means Flutter is the wrong call by default. Google Pay runs on Flutter in production at global scale. Alibaba’s Xianyu resale marketplace, one of the most-cited large-scale Flutter deployments, has run on it for years with hundreds of millions of users. For a team building a standard mobile app, an internal tool, or an MVP that needs to prove product-market fit across iOS and Android fast, Flutter’s single-codebase economics are still hard to beat.
Choosing Flutter isn’t the mistake. Choosing it, or dropping it, based on hype instead of your own hiring runway and your app’s actual technical demands is.
A Framework for Deciding, Not a Verdict
Before defaulting to whatever framework is loudest on X this month, a founder or CTO should be able to answer four questions plainly:
- How fast do we realistically need to scale the mobile team, and can we hire for this stack at that pace?
- Does any part of this product need sub-16ms native latency, deep hardware access, or heavy platform-specific SDK work?
- If the team behind our chosen framework shrinks again, what’s our actual exposure?
- Are we optimizing for time-to-first-version or for a five-year maintenance horizon?
Should a startup still choose Flutter in 2026? For most early-stage products, yes, especially when speed to a working cross-platform app matters more than deep native integration. The calculus changes for teams planning to scale engineering headcount quickly, or for products with real-time hardware or platform-specific demands, where the hiring pool and technical ceiling both start working against Flutter at the same time.
This is exactly the kind of decision that’s easy to get wrong in isolation, because the tradeoffs live in different departments: engineering feels the technical ceiling, recruiting feels the hiring pool, and finance feels the cost of a mid-project rewrite. Getting an outside, technically grounded second opinion before committing to a mobile stack, whether that’s through a fractional CTO engagement or a dedicated engineering team, tends to be far cheaper than discovering the tradeoff eighteen months in.
Frequently Asked Questions
Is Flutter dead in 2026?
No. Flutter is still actively developed by Google, still receives regular stable releases, and still runs large production apps like Google Pay and Alibaba’s Xianyu marketplace. What changed is confidence in its long-term team stability after Google’s April 2024 layoffs, not the framework’s technical viability.
Why are companies moving away from Flutter?
Most teams leaving Flutter cite two real reasons: a shrinking pool of experienced Dart developers that makes fast hiring difficult, and a technical ceiling around low-latency native hardware access caused by Flutter’s platform channel bridge. Very few leave purely over rendering performance or bugs.
Is React Native a safer choice than Flutter for hiring?
For pure hiring depth, yes. JavaScript and TypeScript developers vastly outnumber Dart developers, so React Native and native stacks generally give a team a larger pool to recruit from as it scales past the founding engineers.
Do the 2024 Google layoffs mean Flutter will be discontinued?
There’s no evidence of that. Google’s Flutter leadership publicly reaffirmed commitment to the framework after the layoffs, and Flutter has continued shipping releases since. The layoffs are relevant as a governance and risk signal, not as proof of discontinuation.
Should an early-stage startup still build its MVP in Flutter?
For most early-stage products without heavy native hardware requirements, Flutter’s single-codebase speed still makes it a reasonable default. The risk mainly applies to teams planning rapid engineering headcount growth or products needing deep native or real-time hardware integration.
Conclusion
Flutter isn’t dying. What’s dying is the idea that a framework choice is purely a technical decision. It’s a bet on an ecosystem’s hiring pool and governance stability just as much as it’s a bet on rendering speed, and the teams quietly walking away from Flutter are the ones who did that math honestly instead of emotionally.
If you’re weighing Flutter against React Native or native for a product that needs to scale past your founding team, we can walk through the actual tradeoffs for your specific case, not the generic ones. Talk to us about your mobile roadmap.
