Flutter - free resource mobile app, desktop, web

Impeller has been the only renderer on iOS for years and the default on Android API 29+ for a while. Flutter 3.47 finishes the job: Impeller is now the default on macOS, Windows and Linux. Only Flutter Web still runs on Skia.

If you ship desktop apps, this is the change in 3.47 most likely to alter how your app actually looks and feels — and the one most likely to surface a rendering bug you have never seen before.

The problem Impeller was built to solve

Skia compiles shaders at runtime, on demand, the first time a particular drawing operation appears. That is why a Flutter app could stutter the first time you opened a specific screen, ran a specific animation, or applied a specific blur — and then run perfectly forever after. It was not your code. It was the renderer compiling a program mid-frame.

Impeller compiles a smaller, simpler set of shaders offline, at engine build time. Pipeline state objects are built upfront rather than per frame. Caching is explicit and engine-controlled rather than implicit. The result is not necessarily a higher peak frame rate — it is predictable frame timing, which is what users actually perceive as smoothness.

The design goals are worth naming because they explain the trade-offs:

• Predictable performance — everything compiled offline
• Instrumentable — graphics resources are tagged, and animations can be captured and persisted without perturbing frame times
• Portable — shaders authored once, converted per backend
• Modern APIs — uses Metal and Vulkan features without requiring them
• Concurrent — a single frame’s work is spread across threads

Which backend runs where

Vulkan on Windows and Linux is the line to read twice. Your users’ driver situation is now part of your rendering stack in a way it was not before, and that variability is exactly why you should test on real hardware rather than one developer machine.

Wide gamut color on macOS

Alongside the renderer switch, wide gamut color is enabled by default on macOS. On a P3 display, saturated colors will render more saturated than they did under the previous default. This is correct behaviour, but it is a visible change: if your brand colors were tuned by eye against an sRGB-clamped render, they will look different. Check your palette against design before assuming it is a bug.

How to opt out, per platform

The escape hatches exist, and the release notes are explicit that fallback options will be removed in a future release. Use them to unblock a shipping deadline and to file a bug — not as a long-term configuration.

For debugging on any desktop platform:

flutter run --no-enable-impeller

For release builds, macOS — in Info.plist, under the top-level <dict>:

<key>FLTEnableImpeller</key>
<false />

For release builds, Linux — in linux/runner/my_application.cc:

g_autoptr(FlDartProject) project = fl_dart_project_new();
fl_dart_project_set_enable_impeller(project, FALSE);

For release builds, Windows — in windows\runner\main.cpp:

flutter::DartProject project(L"data");
project.set_impeller_switch(flutter::ImpellerSwitch::Disabled);

On Android the equivalent is a manifest entry (io.flutter.embedding.android.EnableImpeller set to false). On iOS there is no opt-out at all — which is a preview of where desktop is heading.

What to actually re-test

Renderer swaps surface issues in a predictable set of places. Prioritise:

• Blurs and shadows — BackdropFilter, ImageFilter.blur, elevation shadows. Historically the highest-variance area between renderers.
• Custom painters and shaders — anything using CustomPainter, FragmentProgram, or blend modes beyond srcOver.
• Text rendering at small sizes — subpixel positioning and hinting differ.
• Colors on P3 displays — see wide gamut above.
• Clipping and anti-aliasing edges — especially nested clips with rounded corners.
• Startup on low-end GPUs — the Vulkan path on Windows and Linux is the new variable.

The Q2 2026 survey puts Windows satisfaction at 74% and Linux at 73% — the two lowest platform scores after Cupertino. Desktop is where Flutter has the most ground to make up, which cuts both ways: this release is a real investment in those platforms, and it is also the area with the thinnest prior testing.

Filing a useful bug

If you find a regression, the Flutter team asks for a specific bundle, and reports missing it tend to stall:

1. Prefix the issue title with [Impeller].
2. Include device specifications, including the exact chip and GPU driver version.
3. Attach screenshots or a screen recording, ideally side by side with --no-enable-impeller.
4. Attach a zipped performance trace export.
5. State the Flutter version and channel from flutter --version.

The side-by-side comparison is the highest-value item. It converts “this looks wrong” into a reproducible rendering difference.

Your upgrade checklist

1. Build your desktop targets on 3.47 before touching anything else.
2. Run your visual regression suite, or if you do not have one, walk your five most complex screens manually.
3. Compare against --no-enable-impeller for anything that looks off, so you know whether the renderer is actually the cause.
4. Test on at least one low-end Windows GPU and one Linux distribution you do not develop on.
5. Re-check brand colors on a P3 display if you ship on macOS.
6. File [Impeller]-prefixed bugs now, while the fallback still exists.
7. Do not ship the opt-out permanently. Track it as technical debt with a removal date.

The bottom line

Impeller on desktop is the right change and a slightly risky one. The upside is structural: shader jank stops being a category of bug you have to chase, and frame timing becomes predictable. The cost is a one-time re-verification pass over your visual layer, and a new dependency on Vulkan driver quality on Windows and Linux. Do that pass now, while --no-enable-impeller still exists to tell you whether the renderer is at fault — because it will not exist forever.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

The most interesting consequence of Impeller is not smoother scrolling. It is that Flutter now has a rendering backend modern enough to expose a low-level graphics API — flutter_gpu — and that a real 3D engine has been built on top of it.

Now that Impeller is the default renderer on every platform except web, that API’s reach is wider than it has ever been. This article is about what actually exists today, and where the line between “impressive demo” and “ship it” currently sits.

What Flutter GPU is

flutter_gpu is a thin, low-level API over Impeller’s rendering primitives — command buffers, render passes, textures, and shader pipelines. It is not a scene graph and it is not widgets. It is the layer you use when you want to draw things Flutter’s painting API cannot express: custom renderers, particle systems, post-processing, 3D.

Shaders are authored separately and compiled into shader bundles at build time, using flutter_gpu_shaders and build_runner. That is consistent with Impeller’s whole philosophy: pay the compilation cost during the build, never mid-frame.

The mental model that helps: CustomPainter gives you a canvas, FragmentProgram gives you one shader stage over a rectangle, and flutter_gpu gives you the actual pipeline.

flutter_scene: the engine on top

Writing raw GPU code is not what most developers want. flutter_scene — published by the verified bdero.dev publisher, currently at 0.20.0 — describes itself as a flexible realtime 3D engine for Flutter games and apps, with glTF models, physics, skeletal animation, and PBR lighting.

The API is shaped the way a Flutter developer would expect:

• SceneView — the widget you drop into a tree to render a scene
• SceneNode, SceneMesh, SceneModel — the declarative widget API for scene contents
• glTF import at runtime, or a pre-converted .fsceneb binary at build time
• .fscene as a scene description format, with prefab support

That last pair matters for real apps. Parsing glTF at runtime is convenient during development and expensive at startup; the pre-converted .fsceneb path is what you ship.

Platform coverage follows Impeller — iOS, Android, macOS, Windows, Linux — plus web via WebGL2, which is notable given that Impeller itself is not yet available for Flutter Web.

Getting set up

The setup is more involved than a normal package, because native assets and GPU access both have to be turned on:

flutter config --enable-native-assets
flutter config --enable-dart-data-assets   # optional, for DataAssets

flutter create . --platforms=macos,ios,android,linux,windows,web

flutter run --enable-flutter-gpu --enable-impeller

The one that will stop you: flutter_scene currently requires the Flutter master channel, not stable. Version 0.19.0 needed a master build from June 9, 2026 or later for render-to-mip-level support. That is the single most important fact in this article for planning purposes.

How capable is it really

Community demos are the honest evidence here, and they are more convincing than the version number suggests. Brandon DeRosier — the author of flutter_scene — has demonstrated a Scene Editor running on Flutter 3.47 stable, and a port of Godot’s Third Person Shooter demo: roughly 617 MiB of cooked content, 1,795,763 unique vertices, 659,079 unique triangles, and 320 collision meshes, rendering through Flutter GPU and Impeller.

The framing he uses is the part worth repeating: no forks, no platform views, no secondary rendering context. This is not a Unity view embedded in a Flutter app. It is Flutter’s own graphics stack drawing the scene, which means your 3D content and your widgets share a compositor, a frame budget, and an input pipeline.

Other developers have reported flutter_gpu plus Impeller rendering on the order of 20,000 images at roughly 120fps across multiple platforms — the kind of throughput that was simply not expressible through the widget layer before.

Choosing between the layers

Read that table as a ladder, and take the lowest rung that solves your problem. Most apps asking for “3D” want a rotating product model or a data visualisation, and flutter_scene handles that comfortably. Very few want an engine.

The honest maturity assessment

Things that are genuinely true today: the graphics stack is real, the performance numbers are real, and the integration story — one compositor, no platform views — is better than any embedding approach.

Things you should weigh before betting a roadmap on it:

• Master-channel requirement means no stable-channel guarantees, no long-term support window, and a real chance of breakage on any given day.
• 0.x versioning means the API can change under you.
• The package is a community project by an individual publisher, not a Google-supported product. The Q2 2026 survey found developers trust community “battle-tested” features at 41% versus 26% for Google-built ones, so that is not automatically a negative — but it is a different support model.
• Tooling is thin. There is a Scene Editor, but nothing resembling Unity’s ecosystem.

If you want to try it

1. Switch a scratch project to the master channel. Do not do this in your production repo.
2. Enable native assets and generate platform stubs with the commands above.
3. Run with --enable-flutter-gpu --enable-impeller and confirm you get a frame before writing any real code.
4. Start with flutter_scene, not raw flutter_gpu. Drop a SceneView in and load a glTF model.
5. Pre-convert assets to .fsceneb as soon as you care about startup time.
6. Profile on your worst target device early — GPU-bound work exposes hardware differences far faster than widget code does.
7. Pin your Flutter commit hash in CI, since master moves daily.

The bottom line

Flutter GPU is the clearest evidence that Impeller was an architectural investment rather than a performance patch. A single developer building a credible 3D engine on top of it — one that ports a Godot demo with 1.8 million vertices without forking the framework — says more about the foundation than any release note. Just be clear-eyed about the current state: this is a master-channel, 0.x, community-maintained stack. Prototype on it enthusiastically. Ship on it only if you are comfortable tracking master.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

The Q2 2026 survey contains one statistic that reframes how Flutter tooling should be designed: Claude Code at 32% adoption and Antigravity at 23%, both ahead of GitHub Copilot (19%), Cursor (18%) and Codex (17%). Agentic tools have overtaken the autocomplete generation. Roughly a third of Flutter developers now have an agent writing meaningful amounts of their code.

Which creates a problem the framework itself has to solve, because Flutter moves faster than model training data. Flutter 3.47 just changed the import path for the two most-used libraries in the ecosystem. Every model trained before August 2026 will confidently write package:flutter/material.dart forever.

Agent Skills are Google’s answer.

What a Skill actually is

A Skill is a task-oriented instruction set that teaches an agent how to perform a specific development job — not reference documentation, but a procedure.

The framing from the announcement is the clearest way to hold this in your head: MCP provides the hammer and nails; a Skill provides the blueprint and the professional know-how to build the house. An MCP server gives an agent capabilities — run the analyzer, launch a simulator, read a file. A Skill tells it what good work looks like when using those capabilities.

The practical consequence is token efficiency. Skills load progressively, only when relevant to what you asked for. You are not pasting a style guide into every prompt and paying for it on every turn.

The ten Flutter skills

The flutter/skills repository ships these:

• flutter-add-integration-test — configures Flutter Driver and converts interactions into permanent integration tests
• flutter-add-widget-test — component-level testing with WidgetTester to verify rendering and interaction
• flutter-add-widget-preview — adds interactive widget previews for UI component validation
• flutter-apply-architecture-best-practices — structures an app along the recommended UI / Logic / Data layering
• flutter-build-responsive-layout — adaptive layouts using LayoutBuilder, MediaQuery, or Expanded/Flexible
• flutter-fix-layout-issues — resolves overflow and unbounded-constraint errors
• flutter-implement-json-serialization — model classes with fromJson and toJson
• flutter-setup-declarative-routing — configures MaterialApp.router with a package like go_router
• flutter-setup-localization — initialises localization with flutter_localizations and intl
• flutter-use-http-package — REST requests with the http package

The Dart skills live separately in dart-lang/skills, covering language-level work such as pattern-matching refactors and collecting LCOV coverage.

Look at that list as a set and the selection logic becomes obvious. These are not exotic tasks. They are the jobs where an agent left to its own devices produces something that compiles, runs, and is subtly wrong — a layout that works on one screen size, a router configured imperatively, a model class that silently drops a nullable field.

Installing them

Skills install through a single command per repository:

npx skills add flutter/skills --skill '*' --agent universal
npx skills add dart-lang/skills --skill '*' --agent universal

You then select the skills you want and the agent you use. The --agent universal target is what makes this portable across the tools in that survey chart rather than tied to one vendor.

Installing everything with '*' is the fast path. For a team repository, being selective is usually better — install the skills that match your actual conventions, and leave out the ones that would fight your existing architecture.

Where this pays off most

The highest-value case is exactly the situation Flutter 3.47 created. Consider what an agent with stale knowledge produces today:

// What a model trained before August 2026 writes
import 'package:flutter/material.dart';

// What Flutter 3.47 wants
import 'package:material_ui/material_ui.dart';

Both compile right now, because the SDK libraries still exist. One of them starts emitting deprecation warnings in November. An agent has no way to know which is current unless something tells it — and “something” is either a Skill, an MCP server exposing live docs, or you correcting it every single time.

The same applies to @Preview annotations, Impeller-aware performance advice, and Swift Package Manager rather than CocoaPods. Every one of those changed inside the last two releases.

Skills do not replace review

Worth stating plainly, because the survey has a relevant number: developers trust community “battle-tested” features at 41% versus 26% for Google-built features. That scepticism is healthy and should extend here.

A Skill improves the distribution of an agent’s output — fewer wrong-by-default answers, more consistency with framework conventions. It does not make the output correct. flutter-apply-architecture-best-practices will impose a layering on your codebase; whether that layering suits your app is your call, not the agent’s.

Read the generated diff. Run the tests. The Skill has made the agent a better junior, not a senior.

Getting set up

1. Check which agent you actually use. VS Code (66%) and Android Studio (40%) remain where most Flutter work happens; install for the agent running inside your editor.
2. Run both npx skills add commands for flutter/skills and dart-lang/skills.
3. Start selective. Install flutter-fix-layout-issues and flutter-add-widget-test first — the two with the least architectural opinion.
4. Test on a known task. Ask the agent to write a widget test for an existing component and compare against what you would have written.
5. Add the opinionated ones — architecture, routing — only after you have confirmed they match your conventions.
6. Pin your framework version in the prompt when working on migration-sensitive code. Skills help; explicit context helps more.
7. Re-run the install after major releases so the skill definitions track the framework.

The bottom line

The interesting thing about Agent Skills is not that Google shipped an AI feature. It is the admission behind it: a third of the user base now writes code through an agent, and the framework’s release cadence has outrun the models’ knowledge cutoffs. Skills are infrastructure for that gap. They will not make your agent a senior Flutter engineer, but they will stop it confidently importing a library that gets deprecated in November — and on a codebase of any size, that is worth the two commands.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

Flutter 3.47 landed on August 13, 2026, and for once the headline is not a feature — it is an architectural split. The design system is moving out of the SDK. Add Impeller becoming the default renderer on every desktop platform and Widget Previews going stable, and this is the most structurally significant Flutter release in years.

The numbers behind it: 1,356 commits from 169 contributors, 66 of them first-timers, shipping as Flutter 3.47.0 • Dart 3.13.0 • DevTools 2.60.0.

Material and Cupertino become packages you choose

The change everyone is talking about: material_ui and cupertino_ui are now standalone packages on pub.dev, both at 1.0. The libraries still live inside the SDK for now, but the SDK copies are scheduled for formal deprecation in the November stable release.

Why this matters more than it sounds:

• Design systems can now ship on their own clock. Instead of waiting for a quarterly SDK release, Material and Cupertino can iterate weekly. Cupertino in particular needs it — see the survey numbers below.
• You can pin your design system independently of your framework version. Upgrading Flutter no longer means swallowing every widget change at the same time.
• Apps that use neither can drop both. If you ship a fully custom design system, the Material tree stops being a mandatory dependency.

Migration is a one-liner:

dart fix --apply --code=migrate_design_widgets

For the messy middle — your app migrated but a dependency still imports the old paths — there is a MaterialUiCompatibilityBridge to keep both worlds talking.

Impeller is now the default on macOS, Windows and Linux

Impeller replaces Skia as the default renderer across all three desktop platforms. The practical payoff is the same one mobile got: shaders are compiled at build time, so shader compilation jank goes away. On macOS, wide gamut color is on by default as well.

There are opt-outs per platform, but the blog is blunt that fallback options will be removed in a future release. Treat the opt-out as a bug-reporting window, not a long-term strategy.

Widget Previews graduate to stable

Widget Preview is no longer experimental. The stable version adds local caching for faster startup and abstract theme APIs, so a preview can be rendered against multiple themes without wiring up a full app shell. If you tried previews in an earlier release and found them slow, this is the version to retry.

The upgrade tax: iOS 15 and macOS 12 minimums

To support Xcode 27, the floors moved:

Apps also need to adopt the UIScene lifecycle for iOS 27 compliance. If you skipped that migration when 3.44 flagged it, this is where it stops being optional.

Web: Wasm keeps inching toward default

The WebAssembly story from the 2026 roadmap continues. You can build with:

flutter build web --release --wasm

New this release: experimental deferred loading for Wasm behind --enable-wasm-deferred-loading. The prerequisite is still the same — migrate off legacy dart:html to package:web before you expect any of this to work cleanly.

On the plugin side, 92 of the top 100 iOS plugins have migrated to Swift Package Manager. The CocoaPods era is ending faster than most upgrade guides assume.

What the Q2 2026 survey says about where Flutter actually hurts

Google published the Q2 2026 survey results the same week — 3,500+ complete responses collected June 8–22, 2026 — and it reads as the subtext for this release.

The good news is unusually good:

• 93% overall satisfaction, with 58% “very satisfied” (up 6 points from Q4 2025)
• 83% trust Flutter to meet their needs, up from 77%
• For the first time, every developer subgroup cleared 90% satisfaction

Then the outlier:

• Cupertino widgets: 61% satisfaction, down 6 points — the lowest-rated area in the survey, against 92% for Dart, 91% for Android, 90% for the core framework.

Which is exactly why decoupling Cupertino into a package that can ship weekly is the fix, not a refactor for its own sake.

The top pain points name the rest of the release, too: platform/ecosystem maturity (44%), driven by version-matrix complexity during upgrades, then tooling and IDE experience (33%), then bugs and stability (24%).

One more number worth sitting with: developers trust community “battle-tested” features at 41% versus 26% for Google-built features, and trust in Flutter runs 20+ points ahead of trust in Google (83% vs 62%).

The AI trend line: agents are now a first-class Flutter workflow

The survey’s AI section is the clearest signal of where the ecosystem is heading. On adoption:

• Claude Code — 32%
• Antigravity — 23%
• GitHub Copilot — 19%
• Cursor — 18%
• Codex — 17%

Agentic tools now lead the pack, ahead of the autocomplete generation. VS Code (66%) and Android Studio (40%) remain the editors those agents run inside.

Google is building for that directly. Skills for Dart and Flutter, announced in May 2026, are task-oriented instruction sets that teach an AI agent how to do a specific Flutter job — the initial five cover integration testing, localization, responsive layouts, pattern-matching refactors, and test coverage. The framing from the announcement is the useful mental model: MCP gives an agent tools; a Skill gives it the blueprint and the professional know-how. They load progressively, only when relevant, which keeps token usage down.

The problem being solved is the one every Flutter developer using an LLM has hit: the framework moves faster than model training data. A release like 3.47, which changes import paths for the two most-used libraries in the ecosystem, is exactly the kind of change a stale model will get confidently wrong.

Your upgrade checklist

1. Run dart fix --apply --code=migrate_design_widgets and move to material_ui / cupertino_ui before the November deprecation.
2. Audit dependencies for packages still importing the SDK design libraries; use MaterialUiCompatibilityBridge while you wait on them.
3. Bump your deployment targets to iOS 15 / macOS 12 and finish the UIScene migration.
4. Smoke-test desktop builds under Impeller — and file bugs now while the Skia fallback still exists.
5. Retry Widget Previews if the experimental version put you off.
6. Test a Wasm build and check whether deferred loading helps your bundle.
7. Point your AI agent at the Dart & Flutter Skills so it stops generating 3.44-era imports.

The bottom line

Flutter 3.47 is the release where Flutter stops being one monolith. Material and Cupertino become packages you version yourself, Impeller finishes its takeover on desktop, and previews become a normal part of the loop. The survey explains the strategy: satisfaction is high almost everywhere, Cupertino is the exception, and shipping design systems on their own schedule is how you fix that without holding the SDK hostage. Budget an afternoon for the migration — but do it before November, when the old imports start warning.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

The latest stable Flutter release, Flutter 3.44, is one of the most consequential updates of the year for teams shipping to Apple platforms and the web. The documentation was last refreshed on July 10, 2026, and the release notes read like a checklist of the pain points cross-platform developers have been asking Google to fix.

Full iOS 26 and macOS 26 support

Flutter 3.44 (building on 3.38) fully supports the iOS 26, Xcode 26, and macOS 26 releases. That is the headline for most teams: as Apple shipped its Liquid Glass redesign and a new toolchain, Flutter kept pace so you can build and submit against the current SDK without hacks.

There is one migration to be aware of. Flutter now supports Apple’s mandated UIScene lifecycle, and code migration is required to adopt it. If you maintain an iOS Flutter app, this is the upgrade task to schedule — it is mechanical, but it is not optional going forward.

Cupertino Squircles land

Apple’s rounded corners have never been simple circles — they use continuous curvature, the “squircle.” Flutter 3.44 introduces Cupertino Squircles via a new RSuperellipse shape that matches Apple’s native rounded corners. This required deep changes in the rendering engine, and it closes one of the last visible gaps between a Flutter iOS app and a native one. On iOS 26, where Liquid Glass makes shape and light more prominent, getting corners exactly right matters.

Stateful hot reload becomes the default on web

For anyone who builds Flutter Web, this is the quality-of-life win of the release: stateful hot reload on web is now the default. You no longer lose your navigation stack, form inputs, or scroll position when you hot reload. It brings web development to parity with the native mobile experience Flutter developers have enjoyed for years — a genuinely different day-to-day feel.

Security: Android screen-share protection

On Android, developers can now protect sensitive content when users share their screen — hiding customer information, account numbers, and other private data from screen recordings and casts. For fintech, healthcare, and banking apps, this is a feature that previously required native platform code and now ships in the framework.

What to do with this release

• Schedule the UIScene migration if you ship to iOS. It is required for future compatibility.
• Adopt RSuperellipse for cards, buttons, and sheets on iOS to match native corner geometry.
• Re-test your web build with the new hot reload default — the workflow improvement is significant enough to change how you develop.
• Add screen-share protection to any screen that shows sensitive data on Android.

The bottom line

Flutter 3.44 is a “catch up to the platforms and polish the edges” release, and that is exactly what mature cross-platform frameworks should ship. Full iOS 26 and macOS 26 support keeps you current with Apple; Squircles and screen protection close native gaps; and stateful web hot reload quietly makes Flutter Web a much nicer place to work. If you have been putting off an upgrade, 3.44 is worth the afternoon.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

Every year the Flutter team publishes a roadmap, and the 2026 edition is unusually concrete about direction even as it avoids version-number promises. The team has committed to four stable and twelve beta releases this year, and — notably — stated it is not investing in built-in code push. What it is investing in tells you where cross-platform development is heading.

WebAssembly becomes the default for web

The biggest technical bet is WebAssembly. Flutter is on track to make Wasm the default output for Flutter Web, after preparing with Wasm dry-runs in 3.35 and later builds. The payoff is real: in the team’s tests, WebAssembly compilation delivered 40% faster load times and 30% less runtime memory. For anyone who has hesitated to ship serious apps on Flutter Web because of startup cost, this is the change that moves the needle.

Flutter comes to the living room

Google announced a collaboration with LG to bring Flutter to LG smart TVs, with an official Flutter-on-webOS SDK targeting a first-half-2026 release. TVs are a genuinely new surface for Flutter, and an official SDK — rather than a community port — signals that Google sees the framework as a way to write once and ship to phones, desktops, the web, and now the living room.

iOS plugins move to Swift Package Manager

On the Apple side, the roadmap commits to Swift Package Manager becoming the default iOS plugin option, replacing the CocoaPods-centric workflow many teams still use. More experimentally, the team is working on direct calls from Dart to Swift/Objective-C and Java/Kotlin without platform channels — a change that would cut boilerplate and latency at the native boundary. If it lands, writing plugins gets meaningfully simpler.

The real goal: platform parity

Underneath the specific features is a single stated objective for 2026: platform parity — erasing the “uncanny valley” where a Flutter app feels close to native but falls just short. You can see this thread in recent releases already: Cupertino Squircles matching Apple’s corner geometry, full iOS 26 and macOS 26 support, and Android screen-share protection. The roadmap is the same idea pointed forward.

A note on Flutter 4.0

Despite a steady stream of blog posts, Flutter 4.0 has not been officially released. It is speculated for mid-2026 and would be the first major version bump since 2022, but the official roadmap makes no version promise. Treat “Flutter 4.0 feature” articles claiming specific details as speculation until the Flutter team says otherwise; the authoritative sources are the official release notes and the flutter-announce group.

What to plan for

• Test your web build under Wasm. If Wasm is becoming the default, validate your app there before it becomes mandatory.
• Migrate plugins toward Swift Package Manager as the default shifts on iOS.
• Watch the new surfaces. LG webOS support means “Flutter developer” may soon include TV apps.

The bottom line

Flutter’s 2026 roadmap is pragmatic: faster, lighter web via WebAssembly; a real path onto TVs; a cleaner native plugin story on iOS; and a relentless focus on closing the last gaps with native. No grand version-number theatrics — just the unglamorous work of making one codebase feel genuinely at home everywhere it runs.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.

Dart 3.13 ships alongside Flutter 3.47, and its headline feature is the one Dart developers have been asking for since the language got null safety: primary constructors are stable. Declare your fields and your constructor in the class header, and delete the three-line ceremony that every model class in your codebase currently repeats.

There is also a breaking change hiding in the release, and it is not the one most people expect.

The basic shape

The traditional form:

class Point {
  int x;
  int y;
  Point(this.x, this.y);
}

The primary constructor form:

class Point(var int x, var int y);

That is the entire class. Note the ordering — the modifier comes first, then the type, then the name: var int x, not int var x.

Declaring parameters are the actual feature

This is the part worth understanding properly, because it is where the design is subtler than “shorter syntax”.

A parameter prefixed with var or final is a declaring parameter: it induces an instance field. A parameter without either modifier behaves like an ordinary constructor argument and creates no field at all.

// Creates fields x and y
class Point(var int x, var int y);

// No field created — `name` is just an argument
class User(String name);

That distinction gives you a validation-only constructor for free, without the usual trick of a private field you never read.

For immutable models — which is most of them in a Flutter codebase — use final:

class ConstPoint(final int x, final int y);

Named parameters, and the underscore trick

Named parameters work as you would expect, with one nice detail: a private named parameter automatically exposes a public name to callers.

class User({required var String _name});
// Called as: User(name: 'John Doe')

The field is _name, private to the library. The argument label is name, public. You get encapsulation without writing a constructor that maps one to the other.

Named and private primary constructors

Append a dot and a name after the class identifier:

class Point.custom(var int x, var int y);

// Private — restricts direct instantiation from outside the library
class Point._(var int x, var int y);

The private form is the sealed-ish pattern many packages implement by hand today.

Const primary constructors

Put const before the parameter list:

class ConstPoint const (final int x, final int y) {
  final int z;
  this : z = x + y;
}

The constraints are the ones you would guess from const semantics:

• no body block
• every field must be final and definitely initialised
• initialising expressions must be potentially constant

For Flutter this matters more than it looks. Const widget constructors are a real performance lever, and anything that makes them cheaper to write means more of them get written.

Adding a body without giving up the header

You are not choosing between a primary constructor and constructor logic. this : introduces an initializer list, a body, or both:

class Point(var int x, var int y) {
  this : assert(x >= 0 && y >= 0) {
    print('Point initialized at ($x, $y)');
  }
}

Super parameters forward cleanly:

class Person(final String name, final int age);

class Employee(super.name, super.age, final String role) extends Person;

The scoping rule that will trip you up

There are two scopes, and they resolve the same identifier differently:

Concretely:

class ScopingDemo(var String x, String suffix) {
  final String field = x;  // 'x' is the parameter

  this : {
    x = x.toUpperCase();   // 'x' now refers to the field
    print('$x$suffix');    // 'suffix' is still the parameter
  }
}

Read that twice before you refactor a class with a non-trivial initializer list. It is consistent, but it is not obvious.

Restrictions

Compile-time constraints worth knowing before you start converting classes:

• declaring parameters cannot be late or external
• parameter names cannot collide with existing methods or fields
• parameters are read-only inside the primary initializer scope
• you cannot initialise a field both at its declaration and in the primary constructor
• mixin classes may only declare trivial primary constructors — no parameters, no initializer list, no body
• covariant only works with mutable (var) declaring parameters

The breaking change

Here is the part to plan for. final and var on regular function parameters are now reserved exclusively for primary constructor declaring parameters. Existing code that wrote void f(final int x) becomes invalid.

The lint story changed accordingly: parameter_assignments (Dart 3.13+) replaces the older avoid_final_parameters and var_with_no_type_annotation from 3.12 and earlier.

There is a second, quieter hazard: a method named factory without an explicit return type can now be misparsed as a factory constructor. If you have one, add the return type annotation.

What else is in 3.13

Beyond the language change:

• dart2wasm deferred loading (preview) — dart compile wasm -O2 --enable-deferred-loading, with meaningful initial-page-load improvements over dart2js for large apps
• @RecordUse() in package:meta, enabling native libraries to be tree-shaken alongside Dart code
• formatter refinements — a fix for misformatting around large collection literals, better method-chain split heuristics, and blank lines between import sections per Effective Dart
• type promotion soundness fix for nested functions
• faster dartdoc rendering on pub.dev via a two-level hash index

Adopting it without churn

1. Upgrade and build. Fix any void f(final int x) parameters the analyzer now rejects.
2. Add explicit return types to any method named factory.
3. Enable parameter_assignments and remove avoid_final_parameters / var_with_no_type_annotation from analysis_options.yaml.
4. Start with plain data classes — DTOs, value objects, freezed-adjacent models. Highest boilerplate reduction, lowest risk.
5. Use the four IDE refactorings to move between primary and in-body constructors rather than editing by hand.
6. Convert const widget constructors next, once you are comfortable with the const form’s constraints.
7. Leave classes with complex initializer lists for last, and re-read the scoping table before you touch them.

The bottom line

Primary constructors are the rare language feature that is purely subtractive: same semantics, less typing, no new concepts once you understand declaring parameters. The var/final restriction on function parameters is a genuine breaking change, but a mechanical one your analyzer will find in a single build. Convert your data classes this week; leave the gnarly ones until you have internalised the two-scope rule.

Originally published on FlutterCook. Read the latest version there — that copy is the one kept up to date.