The summer break is nearly over, and since the recent releases of Flutter 3.47 and Dart 3.13 pack a good punch, a proper update is in order.
So let’s dive into my latest Flutter newsletter!
Author note: while the overall sentiment about my recent newsletters remains positive, some people have criticised them for being too AI-heavy. So I’m pleased to announce that this August edition is exclusively about Flutter and entirely written by me. I hope you’ll like it. 🙂
Flutter 3.47 is here!
The biggest change in Flutter 3.47 is the release of material_ui and cupertino_ui as standalone packages.
This milestone decouples these design systems from the core SDK, meaning you can now update them independently of the core SDK (which follows a quarterly release cycle).
If you want to migrate your existing apps, run this command:
dart fix --apply --code=migrate_design_widgetsHere’s an example:
import 'package:flutter/material.dart';After the migration, it becomes:
import 'package:material_ui/material_ui.dart';The migration is currently opt-in, and the SDK-bundled libraries are scheduled for deprecation in November 2026.
This release also brings a host of updates, including:
- Localization decoupling: Material and Cupertino localization delegates have been moved into their respective UI packages.
- Impeller on desktop: Impeller is now the default renderer on macOS, Windows, and Linux (an opt-out flag is still available).
- Apple platform preparation: Flutter is now ready for the upcoming Xcode 27, iOS 27, and macOS 27 releases. As part of this, the minimum supported versions have been bumped to iOS 15 and macOS 12.
- Intel Mac phase-out: Intel support is being retired. You can opt into ARM64-only macOS builds with:
flutter config --enable-macos-arm64-only - Swift Package Manager: 92 of the top 100 iOS plugins have migrated. CocoaPods is in maintenance mode, making SwiftPM migration increasingly important (besides, no more CocoaPods headaches is a huge win 😅).
- Flutter web: Work continues toward making Wasm the default. Flutter 3.47 adds experimental deferred loading for Wasm applications, while projects must migrate away from
dart:htmltopackage:web. - Desktop improvements: Experimental popup and multi-window APIs, native window handles, sized-to-content windows, Windows/Linux flavors, focus fixes, and better platform integration.
- Widget Previews: Widget Preview is now stable, with faster startup, layered themes, and automatic synchronization of web assets.
- Platform polish: Accessibility, text selection, gestures, scrolling, keyboard behavior, desktop input, and several core widgets received targeted fixes.
The new standalone design packages work well, and the Flutter CLI automatically upgrades your iOS/macOS project files once you build your apps. So this release gets a nice green checkmark from me! ✅
For all the details, read the full announcement:
Dart 3.13
Dart 3.13 ships primary constructors as a stable language feature, allowing concise declarations such as class Point(final int x, final int y);.
It also brings many other improvements:
- WebAssembly deferred loading enters preview for
dart2wasm, potentially improving initial load times for large Flutter and Dart web apps. - dart format improves readability, particularly for method chains, large collection arguments, and separation of Dart, package, and relative imports.
- pub.dev documentation improves with callout boxes and
{@example}directives that embed selected regions from example files. Documentation rendering is also faster for very large packages. - Native libraries can now be tree-shaken using
@RecordUseandpackage:record_use, removing unused C, C++, or Rust symbols and potentially entire unused libraries. - Runtime and compiler work includes a type-promotion soundness fix, greater analyzer/front-end code sharing, DDC module-system consolidation, stronger native heap memory safety, and early dynamic-linking experiments.
Most formatting changes only take effect when a package upgrades its language version to Dart 3.13. Upgrade Dart directly or run flutter upgrade for Flutter projects.
Here’s the full announcement:
📝 Bringing Primary Constructors to Dart
This language feature is big enough that it deserves its own blog post:
As mentioned above, the new syntax allows concise declarations such as this:
class Point(final int x, final int y);Overall, the abbreviated syntax can cut down on boilerplate in a range of scenarios:
Original Dart syntax New abbreviated syntax
--------------------------------------- --------------------------
LongClassName() {} new() {}
LongClassName.name() {} new name() {}
const LongClassName(); const new();
const LongClassName.name(); const new name();
LongClassName(): this.other(); new(): this.other();
LongClassName.name(): this(); new name(): this();
const LongClassName(): this.other(); const new(): this.other();
const LongClassName.name(): this(); const new name(): this();
factory LongClassName() { ... } factory() { ... }
factory LongClassName.name() { ... } factory name() { ... }
factory LongClassName() = D; factory() = D;
factory LongClassName.name() = D; factory name() = D;
const factory LongClassName() = D; const factory() = D;
const factory LongClassName.name() = D; const factory name() = D;If you’re debating whether the new syntax is better, Bob Systrom’s recent post, Bringing Primary Constructors to Dart, offers a deeper look at the design decisions and trade-offs behind this new feature.
But one question remains: How can you migrate?
New lints, fixes, and IDE refactorings help migrate existing classes, but there isn’t an official dart fix command for migrating your entire codebase.
As it turns out, I have already tackled this problem, and the result is a deterministic CLI tool that can safely migrate ~100K lines of code in under a second.
This tool is included in my Agentic Coding Toolkit, but since primary constructors are now stable, I figured it would be nice to make it free for everyone. So I’ve now published it as a free, standalone GitHub repo:
Other Announcements
Aside from the main announcements, I’d like to highlight a couple of other things that might otherwise go unnoticed.
📝 How Flutter stays ahead of iOS releases
There are many things I like about Flutter, including hot reload and tools like dart fix that can help keep your codebase up to date with minimal effort.
But what’s truly impressive is how Flutter absorbs platform changes and complexity so most developers only need to run flutter upgrade and can continue building their apps normally.
In particular, few people appreciate just how much work is needed in preparation for the yearly release cycles for iOS and macOS.
For example, Flutter’s Day 0 support for new iOS releases is the result of months of preparation. After WWDC, the team triages more than a hundred technical sessions, tests every beta, investigates regressions, coordinates fixes with Apple, and updates Flutter’s engine, tooling, and plugin ecosystem before the stable release arrives.
Some changes require major engineering efforts long before they become mandatory. Flutter’s early migration to Apple’s UIScene lifecycle, for example, meant it was ready when iOS began enforcing the requirement.
If you want to learn more, this detailed blog post shares the full story:
📺 Flutter notable commits - July 2026 (listen package is here!)
With so many contributions going into the core SDK, the Flutter team publishes Notable Commits, a curated list of the pull requests that have landed each week.
Recently, they also started publishing these updates with a nice monthly video summary. Here’s the July 2026 edition:
My biggest takeaway from this video is that the core ValueNotifier, ChangeNotifier, and Listenable classes have recently been moved out of the Flutter SDK and into a separate listen package.
Until Next Time
Now that summer is over, I’m planning to return this newsletter to its usual monthly cadence. I’ll also try to strike a better balance between Flutter and AI-related content, and I hope you’ll continue to find it useful.
Thanks for reading, and happy coding!





