Tech
WasmGC, Dart and Flutter: Where It Stands in 2026
June 12, 2026
Back in November 2023 I wrote that WasmGC would let the full Flutter stack run natively in the browser "early next year", at roughly two to three times the speed of the JavaScript build. That prediction landed almost exactly. `flutter build web --wasm` reached the stable channel in May 2024, and Google's own benchmark showed about 2x average and 3x worst-case frame-rendering gains. So this is the receipt: what actually shipped, the honest state of browser support in 2026, and when turning Wasm on is genuinely worth it.
I'm Gareth, CTO at Foresight Mobile. The original post was an excited look at a proposal. This one is a status report on a feature that's now two years mature, written for anyone deciding whether to lean on Flutter web in 2026.
WebAssembly (Wasm) lets code from low-level languages like C, C++ and Rust run in the browser at near-native speed. It's the technology behind Figma's editor and Unity's web games. For years, though, it had a gap that mattered to Dart: no built-in garbage collection.
That's what WasmGC fixed. It adds native garbage-collection support to the WebAssembly runtime, so garbage-collected languages (Dart, Kotlin, Java and others) can compile to Wasm without shipping their own memory-management runtime inside the bundle. Dart is a garbage-collected language, and before WasmGC its only real web target was compiling to JavaScript, because bundling a custom garbage collector into a plain Wasm build was bloated and slow. WasmGC removed that blocker, which let Dart's framework and your app code compile to Wasm directly. Google helped define the WasmGC proposal with the Chrome and V8 team precisely to support languages like Dart, and it's now a finalised web standard rather than an experiment.
The 2023 post made a specific call: full-Wasm Flutter in the browser, early the following year, at two to three times the JavaScript speed. Here's how that aged.
`flutter build web --wasm` reached the stable channel in Flutter 3.22, announced at Google I/O on 14 May 2024. That's the "early next year" call, more or less to the month. And the performance number held up: in Google's internal tests on Chrome, the Wonderous demo app's frame-rendering time improved about 2x on average and 3x in worst-case scenarios when compiled to Wasm instead of JavaScript. Two years on, the docs treat Wasm as a settled feature and reference the current Flutter 3.44 release. This isn't a preview any more.
The part that surprises people is that you don't really choose Wasm or JavaScript. When you build with `--wasm`, Flutter still emits a JavaScript build alongside the Wasm one. At runtime, the app checks whether the browser supports WasmGC: if it does, it loads the Wasm output and the Skwasm renderer (the full Skia engine compiled to Wasm); if it doesn't, it serves the JavaScript build with the CanvasKit renderer instead. The user never sees the difference except in speed. So shipping Wasm is low-risk: where the browser supports it, you get the faster path; everywhere else, the app still works.
This is the question the 2023 post couldn't answer, and it needs splitting in two: does the browser support the WasmGC feature, and does Flutter's Wasm renderer actually run there? They're not the same thing.
On the first question, WasmGC is now baseline. Chrome shipped it in version 119 (the blocker the original post was waiting on), Firefox followed in 120, and Safari enabled it by default from version 18.2 in late 2024. The large majority of global browser usage now supports the feature.
The second question is where the honesty lives. Even after Safari shipped WasmGC, Flutter's specific Wasm renderer kept falling back to JavaScript on Safari because of WebKit-specific bugs. By late 2025 the Flutter team had fixed the critical Safari crash and reported that Safari with Wasm was performing well, but it wasn't switched on by default yet. And there's a harder limit: no browser on iOS can run a Flutter Wasm build at all, because Apple requires every iOS browser, including Chrome and Firefox, to use WebKit. On iOS, Flutter web always falls back to the JavaScript build.
So the honest 2026 picture is this. Wasm reliably lights up on Chrome, Edge and Firefox on desktop. Safari on the desktop is close and may still fall back. Every iPhone and iPad falls back to JavaScript. The fallback is automatic and invisible, but it means the Wasm gains don't yet reach an iPhone-heavy audience.
The original post had a five-part deep-dive into the compiler here. You can skip the internals, but the short version is worth knowing: Dart compiles to Wasm through `dart2wasm`, which shares its front end (parsing, type-checking) with the other Dart compilers, runs type-flow analysis to tree-shake and propagate constants, maps Dart types onto Wasm types, generates Wasm directly, and finishes with Binaryen, a standalone Wasm optimiser that Kotlin's WasmGC toolchain also uses. The interesting nugget is that last one: Dart and Kotlin lean on a shared piece of the WebAssembly ecosystem to get there.
Turning Wasm on isn't always a flag flip, and the reasons are the most useful part of this post.
For the right kind of app, yes, and it costs you almost nothing. If your product is behind a login, an internal tool, a dashboard or a data-heavy web app, your audience skews desktop and Chromium or Firefox, and the workload is render- or compute-heavy (large grids, charts, real-time data, graphics), Wasm is a free, automatic uplift with a safe fallback. One cross-platform codebase already serving mobile and web simply gets a faster web tier wherever the browser supports it, with no extra work. That's the single-codebase story paying off again.
Where I'd hold back is the iPhone-heavy consumer product or the public, SEO-led site. In the first case the gains don't reach your users yet; in the second, speed wasn't the bottleneck. The win is real, but it's conditional, and knowing which side of that line you're on is the whole decision. There's more on where Flutter's performance advantage comes from in our piece on why Flutter outperforms the competition.
If you're weighing Flutter for a web and mobile product and want a straight read on whether Wasm helps your case, get in touch.
Is Flutter web Wasm production-ready in 2026?
Yes. `flutter build web --wasm` has been on the stable channel since Flutter 3.22 in May 2024 and is a mature feature. The build also emits a JavaScript fallback, so the app works in every major browser even where Wasm isn't supported.
Does Flutter Wasm work on iPhone?
Not as Wasm. Apple requires all iOS browsers to use WebKit, and Flutter's Wasm renderer doesn't run there yet, so on iOS the app automatically falls back to the JavaScript build. It still works; it just doesn't get the Wasm speed-up.
How much faster is Flutter web with Wasm?
Google's official benchmark on the Wonderous app showed roughly 2x average and 3x worst-case improvement in frame-rendering time versus the JavaScript build. Community benchmarks report faster load times and lower memory use too, though those figures vary by app.
Why did Dart need WasmGC specifically?
Dart is a garbage-collected language. Before WasmGC, compiling it to plain WebAssembly meant bundling a custom garbage collector into every build, which was bloated and slow. WasmGC added native garbage collection to the runtime, so Dart can compile to Wasm without shipping its own.
