Flutter 3.47 unbundles Material and starts dropping Intel Macs

Flutter 3.47 landed on 12 August 2026, and reading through the official release post on flutter.dev I kept thinking about the same thing: this is not a feature release, it's a maintenance bill.

Most of what changed is a floor being raised. Older iOS versions, older macOS versions, older Android toolchains, older Macs. If you build Flutter apps from Sri Lanka on a second-hand machine and test on whatever Android phone you already own, this release costs you money before it saves you time.

---

🧩 Material and Cupertino are now packages you install

The headline change is structural. Material and Cupertino design libraries now ship as standalone opt-in packages — material_ui 1.0 and cupertino_ui 1.0 — instead of living inside the SDK. The genui package moves to 0.10.0 at the same time.

The Flutter team's argument for the split:

"You can use the latest Cupertino and Material widget styles without being forced to upgrade your entire Flutter SDK version."

That is a genuinely good trade if you maintain client apps. Design-system fixes stop being hostage to SDK upgrades, and the new packages are planned on a weekly release schedule.

The part to write in your calendar: the original in-SDK design libraries are scheduled for formal deprecation in November, at the Fall stable release. That is roughly three months of runway from today. Deprecation is not deletion, but it is the point after which "we'll do it later" starts accumulating interest.

• Small app, one developer? Migrate in a quiet week. Low risk.
• Agency with five client apps on retainer? Scope it now, per client, and decide who pays.
• Course project or portfolio app? Migrate, and put the migration in your commit history. It reads well.

---

📱 The platform floor moved, and it moved a lot

This is where the cost lands. Every number below is a minimum, not a recommendation.

What	Was	Now
iOS	13	15
macOS	10.15	12
Java	—	17
Kotlin Gradle Plugin	—	2.4.0
Android Gradle Plugin	—	9.1.0
Gradle	—	9.3.1
compileSdkVersion	—	API 36
targetSdkVersion	—	API 36
minSdkVersion	—	API 24

The Android column is the one that bites first. AGP 9.1.0 and Gradle 9.3.1 are not drop-in bumps on an app that has sat untouched for a year; plugin compatibility is where these upgrades usually break, not your own code. Budget a day, not an hour, and do it on a branch.

Key takeaway: Flutter 3.47 asks you to upgrade your toolchain, your test devices, and possibly your laptop. Do the audit before you run flutter upgrade, not after.

The iOS 13 → 15 jump also means checking your actual install base rather than assuming. If you ship to a Sri Lankan audience, a meaningful slice of iPhone users are on hand-me-down hardware. Pull the numbers from your analytics before you decide it's fine.

---

💻 Intel Macs are on the way out

The release notes are explicit that Intel Mac support is winding down, with an eventual transition to hard errors. Combined with the macOS minimum moving to 12, that is a slow-motion deadline for a lot of people I know.

Here is why this matters more here than it does in San Francisco: in Sri Lanka, the affordable route into iOS development has always been a used Intel MacBook. Apple Silicon machines carry an import-duty-inflated price tag that a student or a two-person shop does not casually absorb. "Just get an M-series" is advice with a number attached, and the number is large.

Practical options, in the order I'd consider them:

1. Stay on your current Flutter version for iOS release builds and upgrade the Android side independently. Pinning is a valid strategy, not a failure.
2. Move iOS builds to CI — a hosted macOS runner builds the IPA, your Intel Mac stays a code editor. Free tiers on the usual CI providers cover a low release cadence.
3. Budget for Apple Silicon on a real timeline rather than an emergency one. If you bill in dollars, the freelancer USD to LKR calculator is a quick way to work out how many billable hours the machine actually costs you after conversion fees.

Option 2 is what I'd push most small teams toward. It decouples your hardware replacement cycle from your release cycle, which is the actual problem.

---

🖥️ Desktop and web quietly got serious

Underneath the migration noise, the desktop story improved more than the mobile one:

• Impeller is now the default renderer on macOS, Windows and Linux.
• Wide Gamut Color is on by default on macOS.
• Signed Distance Function (SDF) rendering now handles desktop text.
• Popup windows are supported on Linux and Windows.
• Flavors work on Windows and Linux, so dev/staging/prod builds stop being a hack.
• A sized-to-content API for windows.

On web, WebAssembly support gains an experimental deferred loading flag, and the migration from dart:html to package:web is now required rather than encouraged. flutter_localizations has also been unbundled.

That flavors-on-desktop item is small in the notes and large in practice. If you have ever shipped an internal Windows tool to a client office and juggled two builds by hand, you know exactly how much manual process that removes.

Impeller as the desktop default is the change most likely to surface a bug in your app. Test rendering-heavy screens first — custom painters, shaders, heavy text.

---

🧾 What this means for you

My honest read: Flutter 3.47 is a release you plan for, not a release you rush. The upside is real but deferred — a design system that updates on its own schedule, a desktop target that finally behaves like a first-class one. The cost is immediate and lands on whoever maintains old apps.

A sane order of operations:

1. Inventory first. List every Flutter app you maintain, its current SDK, and its Android toolchain versions.
2. Check your install base. iOS 15 and API 24 floors are only safe if your users are above them.
3. Migrate design imports on a branch. You have until the November deprecation; use the time rather than the deadline.
4. Fix your build machine story before it becomes an outage. CI for iOS is the cheapest fix.
5. Upgrade Android tooling separately from everything else, so a Gradle failure doesn't block a design migration.

And one thing I am not going to guess at: the release notes I read don't give upgrade-time estimates or benchmark numbers for Impeller on desktop. Anyone quoting you a percentage improvement is filling in a blank the source left empty. Measure it on your own app.