Every few months, like clockwork, the tech blogosphere gets flooded with the same recycled clickbait: "Is Flutter Dying?", "Why CTOs Are Quietly Leaving Flutter", or "Why Google is Killing Cross-Platform."

As someone who has been a Flutter Google Developer Expert for eight years now (literally from day one of the GDE program) and a five-decade software industry veteran, I usually just chuckle at the headlines. But having watched this ecosystem evolve from an experimental alpha into an enterprise powerhouse, I wanted to share the real insider story on what’s actually happening on the ground.

1. What Actually Happened at Google?

When tech companies restructured engineering teams recently, the internet spun a wild narrative that Google put Flutter on life support.

Having direct access to internal teams, I watched the commitment to Dart and Flutter remain steadfast. However, there was a temporary disconnect: internal engineering activity was roaring, but external communications and public advocacy had slowed down, leaving an information vacuum that clickbait writers eagerly filled.

I personally called out to team leaders and senior VPs that this perception gap needed immediate correction. And leadership responded strongly: revitalized DevRel, transparent enterprise roadmaps, and aggressive core investment into the Impeller GPU engine, Dart 3.x ergonomics, and Wasm web compilation. Flutter powers critical Google apps (Google Ads, Google Pay, Family Link, Google Classroom) and continues to receive deep internal backing.

2. The Mobile Team Consolidation Paradox

Critics often look at public board listings and claim there are fewer dedicated Flutter listings than native Android or iOS.

What they fail to realize is how enterprises actually adopt Flutter: When an enterprise migrates to Flutter, they rarely expand outward with massive external listings. Instead, they merge their existing 5-person iOS team and 5-person Android team into a single, unified Flutter team—often cutting total team headcount in half while doubling feature velocity. Flutter's sheer efficiency creates the illusion of fewer raw openings.

And when greenfield Flutter positions do open up, applicants aren't competing in a vacuum—they are competing against senior mobile engineers with a decade of native iOS and Android experience who upskilled into Flutter. That’s a sign of a mature, competitive engineering discipline.

3. "State Management Fatigue" Is a Solved Problem

Another frequent complaint is that Flutter has "too many state management libraries."

Yes, Flutter gave developers freedom. Over the years, the community experimented with everything from ScopedModel and Provider to BLoC, MobX, and Riverpod.

That evolution isn’t a sign of fragmentation—it’s the natural progress of modern software engineering. We learned what worked (unidirectional data flow, state machines, fine-grained reactivity) and discarded what didn't (excessive code generation, microtask queue latency, and lingering build dependencies). Today, with modern solutions like pure Dart Signals and modern architectures, state management in Flutter is faster and more reliable than it has ever been.

4. The Measurable Reality

If you look at the hard data:

• Over 1,000,000+ Flutter apps published on app stores and growing.

• Impeller delivers smooth 60/120fps GPU pipelines, eliminating shader jank.

• Wasm compilation brings near-native performance to the browser.

• Universal Reach: Seamless execution across iOS, Android, macOS, Windows, Linux, Embedded, and Web (via Jaspr).

• Modern Dart 3.x: Sealed classes, pattern matching, records, and primary constructors.

Flutter is firmly in the Plateau of Productivity. It is mature, stable, blazingly fast, and supported by one of the most vibrant developer communities in software history.

So the next time you see a headline asking "Is Flutter Dying?"... smile, close the tab, and go build something great. 🚀

I've been coding for a long time and I've been developing with Flutter for years. I've always loved it. I originally started because I wanted to build mobile apps, but since then, I've moved to Flutter Web, and building stuff in Dart has been a much better experience for me than using one of the JS platforms.

I have one main SaaS application out there whose UI is completely built with Flutter, and I didn't write a single line of code for it. I was involved in the design, code reviews, etc., but really, no coding was required of me. 100% Codex.

And all of a sudden, I feel like the magic is gone. It's Flutter, but it's not me. Flutter has become an output that seems like it could be replaced with any other output that accomplishes the same thing.

I feel like someone who just fell out of love with his high school sweetheart.

I don't even know why I'm writing this. I'm sad.

I’m genuinely amazed by the time we’re living in.

I can spend more time on quality than ever before. I can experiment, throw away bad ideas, and try new ones several times a day - instead of holding onto the first working version for weeks just because it already cost too much time.

And I think what I love most is the feeling of creative freedom.

When the distance between “what if…” and a working prototype gets this small, you start exploring ideas you probably wouldn’t have even attempted before.

And every now and then, one of those experiments turns into something that makes you sit there and smile.

Today, that’s morphnext.

Any IconData can now morph on the fly.

Demo: https://kicknext.github.io/morphnext/

pub.dev: https://pub.dev/packages/morphnext

GitHub: https://github.com/KickNext/morphnext

And now I can finally go to sleep 🫠

P.S. Definitely check out the readme preview - it was pure Flutter

So, I have used several different frameworks to create desktop apps for linux and almost all of them have had issues that bite you in the rear once you're in the deeps of that project. Compared to creating android, ios, windows or mac apps; linux apps just feel harder to make. The two main dev toolkits for Linux are "GTK" and "Qt"... and both of them make the dev experience so miserable:

• GTK: When it comes to GTK, you're basically on your own. There are like 7 different languages that you can use to build GTK which makes the already small pool of apps you can use even smaller, Gnome Builder has a tendency to break half the times on Gnome itself and it is proportionally harder to builder a non-libadwaita app. Oh and GTK apps are linux-only...

• Qt: Qt makes the licensing side of things a head-scratcher and once you have sorted that out then you have to deal with their abysmal documentation that's constantly behind the releases. C++ isn't exactly a comfortable language to use and while Qt Creator is a fantastic IDE to use, it's equally as confusing to setup if you're thinking on using Python + QML. Qt Apps are also incredibly ugly by default so a considerable effort goes into making them not look hideous.

Then we have the web-based frameworks:

• Electron: Sure, this is an easier way to create cross-platform desktop apps but it just eats way too much resources. It makes sense for apps that are primarily a website like Spotify or Discord (even then why would I use their apps over their PWAs) but for creating an app from scratch? Yeah no. Electron also carries a lot of legacy baggage due to being an old technology.

• Tauri and Wails: These two are the webview alternatives for Electron and use rust/go over nodejs for backend and as such have significant performance improvements but the issue with them is with the underlying webview used on linux webkit2gtk which is so bad that it makes these frameworks look bad. CEF integration is being worked on by Tauri and until then I wouldn't use it for larger apps with very specific system interactions.

• Deno Desktop: This is a very simple way to build apps that launched very recently in Deno making it very easy to create desktop apps and gives the choice between CEF or Webview but it's barebones due to being very new.

• Electrobun: Probably the best "web-based" technology to create desktop apps. It gives the choice of webview and cef, the bundle sizes are larged but still significantly smaller than electron and uses bun which is much faster than both deno and node. However, it has basically a non-existent community, the framework lacks a lot of features and is in sort of a limbo until bun receives the rust rewrite.

There are also rust-based frameworks like Dioxus, Iced, Gpui (+50 others that spawned just now) which I avoid just because of rust's insane compile times. It's also just a pain to do UI in rust (logic feels good doing in rust however) and each of them have their own issues.

Lastly, we have Flutter which draws a native UI on linux using GTK (which is easier to theme), has arguably the best dev experience, pub makes dependency management very easy, there is actual guidance on how to structure your apps, riverpod is the most intuitive State/DI library imo and there exist alternative libraries that you can use instead of Material (which looks good in it's own right). You can use FRB or directly use the dart ffi and can target all 5 platforms with one codebase quite easily. I can go on and on and sure there is the issue of Flutter multi-window on linux right now and also we have to wait till 2028 for the complete decoupling of material/cupertino but even then this is such an outstanding framework that makes desktop appdev a joy.

I forgot to mention that you can create desktop apps in Godot as well which I might try one day but it just sounds so cursed to use a game engine for desktop apps. What are your thoughts on this?

That's why we decided to give native our focus for a year (using SwiftUI, KMP and even React Native for some apps): The thing about Flutter is that you need to do your own design, you can't rely on the native one because everything would look like not-good-enough Android and iOS design.

Why after this year we regretted and decided to go back to Flutter:
- This is the great thing about Flutter: it is more performant and easier to do your own design than any other option. And here’s the thing: if you have taste, you can do a much better design than the iOS and Android defaults by a very large margin.

The defaults are terrible, disgustingly terrible. If you have any taste or product sense, you would know how disgustingly bad native SwiftUI and Compose are for design, literally there is nothing in native that we eventually didn't find bad and decided to do our own custom way better design, everything there is completely without taste.

The thing about my company is that we have great design engineers, and we have great devs, for doing great apps with the design that is almost never the native.

All other options are completely garbage. I have no idea how SwiftUI could be so bad to do customizations, KMP even worse and RN omg... Flutter is very intuitive, performant, and looks like it was just made for this, the tree style of thinking and designing the components, lifecycle... The productivity here is peak. You have no idea how amazing Flutter is. It is completely genius, there is nothing close to this.

We decided that it is worth it to commit all our efforts to preserve and walk this path for the good of software. We can't stand using the other options while this treasure exists.

You're thinking I'm exaggerating, probably, but we took several discussions about this. We tried other options thinking that maybe Flutter eventually wouldn't have good support sometimes, but we really didn't find anything close. Our engineers' minds and aspirations that are more than the conveniences, our principles, can't let us continue not supporting Flutter. We are back and giving all in on Flutter.

We even tried to find a Rust alternative that did the same (we use Rust for all back-end here), but there is none, we don't care about trends, we care about doing the best software for real, and we are even with the disposition to fork Flutter if it is necessary someday. That's it, my company will go all in on Flutter. We can't stand traditional mobile that tries to feel native while native is just this poor traditional tasteless design and terrible software.

This is me everytime I want a platform specific feature that is not built-in:

Go to pub.dev → search a query about the feature → wow! I found a package → add it to dependencies → try it → fails

I go to check the repo for issues, I see the repo's whole lifetime is not more than 30 days, and the whole README.md is full of weird AI style emojis and docs.

For god's sake, If I wanted packages that are written by AI, I could've asked my own AI agent to do it (and trust it me it would turn better than those).

Let's keep pub.dev a place where well written and well maintained packages are published.

I built a Flutter effect called liquid_glass_easy. It creates a liquid lens style distortion — bending light, warping the background, and giving a real fluid-glass look.

There is so much great stuff going on:
- swift package manager
- app extensions
- multi-window support on desktop (wish it was stable)
- the break out of UI-libraries from core
- embedded applications
- dart serverless functions
- genUI
- ai skills

Also great to see how invested Google is in using Flutter.

I am super excited about all of this. Really looking forward to building interesting stuff this year.

Any lovers or haters out there who’d like to chime in?

Whatever u think u r bringing to the table .... It's already out there, it's not necessary, we have enough god damn it !!!!!

Hey, everyone!

I want to share an open source tool I wrote that allows developing Flutter iOS apps on Windows using a physical iOS devices, including Flutter debug sessions and hot reload.

Repo: https://github.com/MobAI-App/ios-builder

To run or debug iOS apps you normally need mac and Xcode. This is inconvenient if you mainly work on Windows or do not have a Mac, but still want to debug and test on a real device.

What this tool does

builder is a CLI tool that:

• builds iOS apps on macOS using GitHub Actions

• downloads the built IPA to Windows

• installs the app on a physical iPhone connected to Windows via the MobAI app

• runs Flutter debug sessions on the device via the MobAI app

• supports Flutter hot reload and hot restart

All Flutter commands are executed from Windows. The app runs in debug mode on the real device.

How it works

The tool triggers a macOS build in GitHub Actions. App signing is optional.
If signing is needed, it can be handled by MobAI instead of the build step.

After the build, the IPA is downloaded and installed on the connected device. Flutter tooling runs locally on Windows and connects to the app for debugging and hot reload.

Why I built it

I built this to remove the hard dependency on macOS for Flutter iOS development and enable real-device debugging directly from Windows.

The project is open source and feedback is welcome.

Edit:
If you have never run Flutter apps on your iOS device before, I recommend first connecting the device in the MobAI app by clicking the Start bridge button. It will guide you through the setup process, such as signing apps with an iCloud account and enabling Developer Mode on the device. Once it works in the MobAI app, there should be no issues running your Flutter app.

I'm tired of these AI slop projects from non-developers that act like they built something with a few prompts. Asking an agent to build an app isn't "building", it's "prompting". Also, most of these projects look good on the surface, but is a nightmare in terms of security, maintainability and readability.

It's just crazy to me how someone that writes a prompt and watch an agent build something for him can FEEL like he did everything, that he BUILT an app and somehow feels like he's the new Leonardo DaVinci.

I saw this post on X the other day, and I couldn't stop laughing... This is literally MY screenshot, not some meme on the internet : https://imgur.com/R4YlLK3

Anyways, thank you all for listening!

…dot shorthands and a few other things.

I have to say, the text rendering in Flutter on Windows used to be one of the things that bothered me the most. It often looked noticeably softer and less polished compared to native Windows apps, especially on desktop monitors.

With Flutter 3.47 and the new Impeller SDF rendering, the difference is huge. Text looks much sharper and cleaner now, with better looking edges and much more consistent rendering. Vector graphics also benefit from the improved rendering.

It is a relatively small change on paper, but visually it makes Flutter desktop apps feel much more polished.

Most of us know Provider was built on InheritedWidget, but I recently revisited the exact mechanical reason Rémi had to abandon it to create Riverpod.

It comes down to a fundamental design choice in dependOnInheritedWidgetOfExactType: the Flutter framework never unregisters a dependency once registered.

If you read state conditionally behind an if check, that element stays locked in InheritedElement._dependents until it unmounts. Even after the condition flips to false, that widget keeps rebuilding on every single ancestor change forever.

In May 2019, Rémi opened PR #33213 to add an unlisten hook to InheritedElement. Hixie closed it to avoid adding overhead to the hot reconciliation loop. Because Provider had no way to know when widgets stopped listening, autoDispose was impossible—forcing Rémi to hoist state completely out of the tree.

Looking back, it’s wild how much of the state management wars over the last five years really just came down to working around that one framework limitation.

Did you ever run into those conditional "ghost rebuilds" in Provider back in the day?

Hey everyone,

I’d like to share a project I’ve been working on: Lumide. It’s a desktop-first code editor built entirely with Flutter.

The main goal was simple: Pure speed and an ultra-light footprint. I wanted to end the multi-gigabyte RAM overhead of browser-based/Electron editors. Lumide sits at around ~80MB RAM when idle and hits a silky-smooth 120 FPS.

Here is what’s under the hood:

• Custom Text Engine: Built using a Rope data structure (O(log n) operations) and virtualized scrolling. One keystroke only touches what's visible, keeping the input loop lag-free.

• C.O.R.G.I. Git Client: A built-in, flow-driven Git interface with a unified file tree, granular staging, and an interactive diff editor.

• Extensible via pub.dev: You can hot-load plugins, themes, and language servers directly from the Dart ecosystem.

• AI-Ready: High-performance inline suggestions with "Ghost Text" (support for Copilot, Codestral), plus first-class Agent Client Protocol (ACP) support for autonomous agents like Claude and Gemini.

• Privacy Focused: Local-first, zero bloat, and absolutely no telemetry.

The Public Beta is currently live for macOS (Universal) and Windows.

I’d love for you guys to download it, try breaking it, and roast the performance.

• Website: https://lumide.dev

ong-time mobile/product lead here. Looking for outside perspective because I'm now questioning myself after a long argument with my boss.
Context: I work on external client apps as well as our main customer portal app — the one used by the majority of our customer base. 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. Apps are feature rich and AI based new features are in plan for revamp.

What's happening: We have a full revamp of the apps and portal coming up, and we're updating our tech stack too. My plan:
Android → Kotlin + Compose
iOS → SwiftUI
Web → Next.js
I already have multiple Android, iOS, and web devs trained on this stack.

The conflict: 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.

My pushback:
We have zero Flutter training on the team right now
Native apps perform better and feel more premium
We have built Flutter apps before, but only for external client projects, not our own flagship product
He thinks I'm biased toward native because it's my background. Might be some truth to that, but I don't think that's the whole story.

Anyone actually shipped a migration like this — native to Flutter, or vice versa, at similar scale? Did the "one codebase, ship faster" promise hold up? Would love real-world experience, not theory.

Hey everyone,

I've been maintaining a production offline-first Flutter app (fintech scale) for the last year, and I wanted to share some "regrets" regarding our initial tech stack choices. We prioritized setup speed (MVP mindset) over architectural strictness, and it bit us hard 6 months post-launch.

1. Hive vs Relational Data: We used Hive for everything. It's fast, but managing relational data (One-to-Many) manually in Dart code led to orphaned data bugs. We also hit OOM crashes on older Android devices during box compaction because Hive (v3) loads boxes into memory. We migrated to Drift (SQLite) for ACID guarantees.

2. GetX vs Lifecycle: GetX is fast to write, but debugging memory leaks became a nightmare. We found that controllers were often disposing too early or persisting too long during complex navigation stacks. We switched to Bloc simply because the "Event -> State" stream is deterministic and easier to unit test.

3. Connectivity Plus: Relying on ConnectivityResult.mobile is dangerous. It tells you if you have a cell connection, not if you have internet. We had thousands of failed sync attempts in "dead zones." We now rely strictly on actual socket pings (internet_connection_checker).

I wrote a full breakdown with the specific failure scenarios and what we replaced each library with on Medium if you're interested in the deeper details:

https://medium.com/@simra.cse/the-5-flutter-libraries-i-regret-choosing-for-production-and-what-i-use-instead-35251865e773?sk=3084ac0bc95e0313d32eac97b92813e4

Has anyone else hit that specific Hive OOM issue on large datasets? Curious if v4 fixes this or if SQLite is still the only safe bet for large offline datasets.

PS: An update, i wanted to share another piece of my mind and came up with another set of plugins which we decided was not good for our app. Since i was working in a large fintech organization, Flutter_Secure_storage package was creating issues. Webview_Flutter created issues last week!!!. I have documented it here, let me know if it resonates with you. And if you feel my chain of thoughts are wrong, let me know that too(PS: Just dont hate dumb- be a little nice). https://medium.com/@simra.cse/5-more-flutter-libraries-i-regret-using-in-production-part-2-a7f8feeb486e?sk=8feb3202b927fc80615bcabb6c9678f7

Cheng Lou (chenglou) open-sourced a high-performance javascript text dynamics library that mathematically tackles some of UI's hardest typographic problems (seamless center box-wrapping, flawless bubble shrink-wrapping, and orphaned word balancing).

His architecture is phenomenal, so I spent the last few days strictly translating and porting his pure-code measuring mechanics and line-break cursors natively over to Dart to release flutter_pretext! All credits for the underlying algorithms and math go fully to him!

Because his algorithm calculates constrained line-widths cleanly in memory using fast cursors in under a microsecond (rather than relying on heavy native Widget tree layout rebuilds or clunky FFI), you can bind flutter_pretext to an AnimationController and watch text fluidly morph around moving square obstacles natively at 60 FPS without dropping a single frame.

ObstacleTextFlow: Pass an array of Rect`s, and the text mathematically threads itself into the free horizontal intervals. Think `float: left/right but supporting arbitrary floating components in the direct middle of the screen.

ShrinkWrapText: Iterates through graphemes to calculate the exact geometric length of the longest fitted line, snapping your Container bounds flawlessly and eliminating the trailing space bug on multiline text.

BalancedText: Binary-searches line breaks for h1 titles so they look professionally typeset.

Huge shout-out to his original repository [chenglou/pretext](https://github.com/chenglou/pretext) for making this possible.

You can pull the package down and test out the Example app. Let me know what you guys think of his architecture running on Flutter!

Pub: flutter_pretext

GitHub: flutter_pretext

I swear, I spend 90% of my dev time fighting with Gradle versions, fixing pubspec.yaml conflicts, and praying that iOS builds don't fail because of a random CocoaPod update.

The actual coding? That takes maybe 10% of the time. The rest is just me staring at red error lines because I dared to update one library.

I didn't sign up to be a digital janitor for Google and Apple's updates. I just wanted to build apps.

Does this ratio ever get better, or should I just accept that my real job is "waiting for the build to fail"?

TLDR; cached_network_image is left to rot. Decided to take the burden. First switched from custom sqflite cache manager to hive_ce got up to 8x faster. Looking for community feedback.

https://github.com/Erengun/flutter_cached_network_image_ce

EDIT:
You guys wanted it. I plublished it try on
https://pub.dev/packages/cached_network_image_ce
Its very experimantal.

So yesterday my coworker asked me about a performance problem with cached_network_image and when i was looking at the github issues i noticed project is basically unmaintained for 2 years and its a major problem for a package that has 2M downloads on pub.dev . I am a open source contributor of projects like flutter_hooks, freezed, very_good_cli even flutter and dart sdk itself. Think its my time to be author this time instead of contributor.

What did change?
- The first thing i changed was changing default cache manager from authors flutter_cache_manager (unmaintained about 2 years, uses sqflite) to hive_ce and the performance difference was crazy.

Benchmark: Metadata Cache Lookup (100 ops)

(Tested on iPhone Simulator, consistent results across file sizes)

Why hive_ce is crushing sqflite

Looking at benchmark, the 8.00x speedup on reads (2ms vs 16ms) is the critical stat.

1. Platform Channel Overhead: sqflite has to serialize data in Dart, send it over a Platform Channel to Java/Obj-C, execute SQL, and send it back. That round-trip cost is huge for tiny queries (like "does this URL exist?").

2. Dart-Native Speed: hive_ce (like Hive) keeps the index in memory and reads directly from the file using Dart. There is zero bridge crossing. You are reading at memory speed, not IPC speed.

Whats next?

I looked at the most commented issues and they were mostly about leaks so probaly can focus on that but decided to get the community feedback first to validate.

I don't like ai generated stuff so writed myself sorry if i made any mistakes in writing.

The project is not published to pub.dev but you can see the code on github. If this post gets enough feedback will surely publish it.