I’m researching how Flutter developers maintain localization once an app grows beyond a couple of languages.

I’m particularly interested in people maintaining real apps with 3+ locales.

I’d love to learn how you currently handle ARB files, translations, adding keys/languages, validation, ICU/plurals, and keeping everything in sync.

I’m a Flutter developer myself and I’m building in the localization space, but I’m currently focused on understanding real workflows rather than promoting anything.

I’m looking for ~5 Flutter developers willing to have a casual 15–20 min chat. If that’s you, comment or DM me.

I’ll also summarize the patterns I find and share them back with the community.

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 learned Flutter a few months ago and have built several small projects.

I’d like to improve the way I structure my Flutter projects before I start building larger ones. Currently, I usually organize my "lib" folder something like this:

lib/

├── main.dart

├── app_theme.dart

├── database/

├── providers/

├── screens/

├── widgets/

└── utils/

Is this a reasonable structure, or would you recommend a different architecture? If so, I’d really appreciate it if you could explain why and when I should use it.

Also, I’ve never worked with databases before. I’d like to learn how databases work and how to properly integrate one into a Flutter app.

Could you recommend some good, up-to-date resources for learning databases and database integration with Flutter?

Thanks!

I’ve been experimenting with Meta Display Glasses recently. Apps for the glasses can be built as web apps, so naturally I wondered: could Flutter Web run on them?

I wasn’t sure it would work well. Flutter Web isn’t exactly lightweight, and the glasses are quite a different target from a regular browser.

After playing with the build and a few configurations, I got it working.

Nothing fancy yet, just the default Flutter counter app. But it runs directly on the glasses display: the Flutter UI is rendered in front of you, and interacting with the controls updates the counter as you’d expect from the same app running in a browser.

What I find more interesting is the potential for existing Flutter apps.

If you wanted to add a companion experience for Display Glasses, you could potentially keep it in the same codebase and reuse your existing logic, models, networking, and some widgets, while building a UI specifically for the glasses.

I have a few things I want to try next. Curious what other Flutter devs would experiment with on a display like this!

Hi, I am an ex-lawyer, from India . I am trying to switch to tech. I learned data science and machine learning so far. I want to know if it is an old idea for me to learn flutter and try for developer roles in 2026. I ask this because people are saying that data science has lost demand in the market.

I want to start a challenge with the Flutter community.
Give me something to build.
It can be anything you think would be a good challenge for a Flutter developer:
📱 A difficult UI/interaction — ideally something that can be built in 1–2 screens
⚡ A challenging animation or custom widget
🧠 A complex Flutter implementation
🔄 An interesting state-management challenge
🎨 A UI from an app that would be difficult to recreate
📦 Something that could become a useful pub.dev package
🛠️ A Flutter developer-tool idea you wish existed
🔥 Or just something you’ve always wanted to see implemented in Flutter
The rules are simple:
You give me the challenge → I build it → I share the result back with the community.
I’m not looking for easy CRUD screens. Give me something that actually makes me think, learn something new, or push Flutter to its limits.
If your challenge is selected, I’ll share the implementation, what I learned, and the final result.
So, what would you challenge me to build?
Drop your hardest/most interesting Flutter challenge below. 👇
Let’s see what the community can come up with.

Since the Flutter team is collecting wasm feedback this week, I wanted numbers where the delta is attributable to codegen alone, not the rendering pipeline. So I wrote a CHIP-8 emulator in pure Dart: interpreter hot loop over Uint8List, zero allocations in the loop, framebuffer blitted in a single CustomPainter. Same source compiled twice — flutter build web vs flutter build web --wasm. Flutter 3.47, both release, same Chrome.

Results:

- dart2wasm: ~130M emulated cycles/sec, and the same number in every environment I tried (interactive window, headless, occluded tab)

- dart2js: 30–51M depending on environment, with a few seconds of JIT warmup before reaching full speed

- speedup: 2.6–4.4x. Migration cost for this codebase: one build flag, zero code changes.

Two things surprised me:

1. The consistency matters more than the multiplier. Wasm runs at full speed from the first frame, everywhere. JS swings by 70% between environments. For anything latency-sensitive, that predictability is the real win.

2. A trap if you benchmark this yourself: if your metric is cycles per wall-clock second, Chrome's requestAnimationFrame throttling (occluded or backgrounded window) silently crushes the number ~4x. I chased that ghost for a while. Normalize by actual compute time, or you're measuring the compositor, not the compiler.

Caveats: one compute-heavy workload, one machine. UI-bound apps will see much smaller gains, and packages relying on legacy dart:html / dart:js interop can block the wasm build entirely — that's the first thing to check on a real codebase.

(It also plays the original 1990 Pong ROM, which was not strictly necessary but was the most fun part.)

Happy to answer questions or share details about the setup.

Join us for Try Flutter Web with WebAssembly Week!

Unlock up to 2x–5x faster web performance with Wasm compilation in Flutter 3.47

Run `flutter build web --wasm`, test your app, and share your wins using #FlutterWasmWeek!

Details: https://flutter.dev/blog/try-flutter-web-with-webassembly-week

I am looking for Flutter open-source projects to contribute to on Github.

I've been building a social/messaging app called Riv with Flutter, and the biggest surprise wasn't actually building the UI.

It was getting all the different real-time pieces to behave like one system.

The app has real-time messaging, presence indicators, group chats, notifications, and multiplayer games. That meant I had to deal with things like state synchronization, reconnects, message delivery, game state, background behavior and keeping the UI responsive while everything was changing underneath it.

The interesting part was that problems that look completely unrelated at first often turned out to be the same underlying problem: what should the client consider authoritative, and what should happen when the client is temporarily out of sync?

I'm still refining the architecture, but the app is now live.

I'm posting this mainly because I'd be interested in hearing how other Flutter developers would approach the architecture differently.

If anyone is interested, I can also break down how I handled the real-time messaging/game state separation.

I'm building a vocabulary-learning app in Flutter where hearing and saying the word correctly is the product, not a nice-to-have. I've hit a problem I can't design around and I'd rather ask than keep patching.

The stack

• Flutter, ~1,600 words live across EN/ES/PT/IT/FR
• TTS: ElevenLabs (eleven_multilingual_v2) called through a Supabase Edge Function so the key never ships in the client
• Every clip cached server-side once per (text, language), shared across all users — so a given string is synthesized exactly once, ever
• Cached again on-device (150MB LRU) so replays are instant and offline
• flutter_tts as fallback behind a 2.5s timeout so playback never goes silent
• STT: speech_to_text for a pronunciation-practice screen — hear the word, say it, get graded

The problem: heteronyms, in both directions

Output. "Wind" (moving air) and "wind" (to coil) are the same string and different sounds. TTS picks one reading and commits. My word library actually knows which sense is on screen — every entry carries a part of speech — but there's no API surface to hand that over. ElevenLabs pronunciation dictionaries are exact-string, case-sensitive, and have no POS or context scoping, so one spelling gets one entry and the second sense is unreachable. Phoneme tags do exist, but per the docs only on eleven_flash_v2 and v3 — not the multilingual model I'm on, and switching models means re-synthesizing the whole cache and losing voice identity across five languages.

Input. This is the part that actually bothers me. The practice screen normalizes the transcript and Levenshtein-scores it against the target. But STT returns orthography — say either reading of "wind" and the transcript is "wind" either way. A learner who mispronounces it scores full marks. The feature is structurally incapable of catching the error it exists to catch.

What I've tried

Respelling the audio-only string before it reaches the engine — the screen text is never touched. wind(noun) → winned, wind(verb) → wined, read(past) → red, and so on. This is basically ElevenLabs' own recommended "alias" workaround and it works for the ~8 vowel-shift pairs I've mapped. Side benefit: since my cache key is a hash of (lang + text), two senses naturally get two cache entries.

It fails in three ways:

1. Stress-shift pairs. REcord/reCORD, PREsent/preSENT, CONtent/conTENT. Respelling can't encode stress, and I haven't found a trick spelling that does.
2. Monolingual. It's an English orthography hack. Nothing about it transfers to ES/PT/IT/FR, all of which have their own homographs.
3. Manual. Hand-curated table. Doesn't scale to a few thousand words.

What I'm actually asking

1. Is there a TTS API that accepts a sense/POS hint, or per-request phonemes, on a multilingual model? Or does everyone route heteronyms to a separate English-only model and eat the voice mismatch?
2. If IPA is the only real answer — has anyone found v3-class IPA reliable enough in production? The docs quote 80–90% consistency, which for a teaching app means the wrong pronunciation ships to a learner one time in eight.
3. For stress-shift specifically: any orthographic trick that works, or is phoneme-level control genuinely the only path?
4. On the STT side — is there a mobile-viable way to get phonemes rather than words? I've looked at wav2vec2 phoneme-CTC or a forced aligner with GOP scoring via ONNX on-device, but I don't know if that's realistic on a mid-range phone or if I'm about to spend a month learning that it isn't. Whisper doesn't help; it also returns orthography.
5. The unglamorous option: detect heteronyms and simply disable pronunciation scoring for them, with an honest note to the user. Is that what shipped apps actually do?

If you've built pronunciation feedback into anything real, I'd love to know where you drew the line between "graded properly" and "good enough." Happy to share code for any of the above.

Imagine ... A country doesn't like an app, the government threatens google, google revokes the developers signing keys ... And now the app can't be installed on any android device in the entire world.

This isn't a conspiracy theory, it's a very real , very close threat.

DO NOT SIGN UP if this gets implemented, fight the urge to submit for the sake of publishing one app.

Read the letter for more details.

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

Started with Riverpod, switched to BLoC and honestly don't regret it .The structure and separation of logic is cleaner for larger projects. But feels overkill sometimes for simple features. Curious what others are using in production and whether you'd make the same choice again.