Flutter - free resource mobile app, desktop, web

macOS 26, named Tahoe, is Apple’s current Mac operating system, and it carries two stories at once. The first is cosmetic and immediate: the Mac now wears Liquid Glass, its biggest design change since 2013. The second is structural and final: Tahoe is the last version of macOS to support Intel Macs. Together they make this a transitional release worth understanding whether you use a Mac or build software for one.

Liquid Glass on the desktop

Apple brought its new translucent material to the Mac, and it goes deep: desktop icons, folders, the Dock, in-app navigation, menus, toolbars, and Control Center all pick up the glass treatment. A transparent menu bar makes the display feel larger, and Liquid Glass sidebars and toolbars reflect and refract the content behind them. Apple also added personalization borrowed from iOS — light, dark, and clear icon tints, plus custom accent and text-highlight colors.

A Phone app on the Mac

One of the more genuinely useful additions is a Phone app for Mac, powered by Continuity, that relays cellular calls from a nearby iPhone. It brings Call Screening, Hold Assist, Live Translation, Recents, Contacts, and Voicemail to the desktop. It is the kind of feature that quietly removes a reason to pick up your phone during focused work.

Spotlight grows up, Launchpad retires

Spotlight is smarter in Tahoe: it surfaces apps, recent and suggested files, actions you can take, and even clipboard history. In exchange, Apple retired Launchpad, replacing it with an App Library–style “Applications” view that organizes apps by category. It is a meaningful change to muscle memory for long-time Mac users.

The Intel cutoff

The most important line for developers is this: macOS Tahoe is the last macOS to support Intel Macs. From macOS 27 — expected in fall 2026 under the name Golden Gate — Intel Macs will not be supported. Tahoe runs on all Apple-silicon Macs plus a small set of Intel models released since 2019.

If you ship a Mac app, this is a planning milestone. Universal binaries and Intel testing have a clear expiry date. Teams can start treating Apple silicon as the sole target for the next major release cycle.

What it means for Flutter and cross-platform desktop

Flutter’s macOS desktop support tracks the current toolchain, and recent releases fully support macOS 26. For teams shipping a Flutter desktop app, Tahoe is a prompt to confirm your builds run cleanly on Apple silicon and to retire any lingering Intel-specific assumptions ahead of the macOS 27 cutoff.

The bottom line

macOS 26 Tahoe is a “look forward, close the door behind you” release. Liquid Glass and the new Phone app modernize the experience, Spotlight becomes genuinely more capable, and the Intel cutoff draws a clean line under a multi-year transition. For developers, the action item is simple: get comfortable on Apple silicon now, because from the next release it is the only game in town.

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

For nine years, the iPhone looked essentially the same. iOS 7 flattened Apple’s software in 2013, and every release since refined that flat, opaque aesthetic without fundamentally changing it. iOS 26, the version currently shipping to iPhones worldwide, ends that era. Its headline feature is Liquid Glass — a translucent material that Apple has threaded through the entire operating system, from the lock screen to app toolbars.

What Liquid Glass actually is

Liquid Glass is a rendering material, not just a color palette. Like real glass, it lets light and the color of whatever sits behind it shine through, refracting and reflecting as content scrolls underneath. Apple describes it as the foundation for “the next decade of iOS design,” which signals this is not a one-release experiment. It is the new baseline.

For users, the effect is immediately visible: transparent toolbars, tab bars that pick up the color of the content behind them, and controls that feel like they are floating above the interface rather than pinned to it. It is the first time since iOS 7 that opening a familiar app feels genuinely new.

Why developers should care

A system-wide material change is never purely cosmetic. When Apple shifts its design language, three things happen for app builders:

• Native components restyle themselves. Apps that use standard UIKit and SwiftUI controls inherit the Liquid Glass look automatically. That is a gift for teams that stuck to the platform defaults — and a warning for teams that hand-rolled custom chrome that now looks dated next to the system.
• Contrast and legibility need re-testing. Translucency means your text and icons sit on a variable, content-dependent background. Layouts that assumed a solid bar behind them can lose contrast. Every screen deserves a fresh accessibility pass.
• Brand UI has to make a choice. Do you lean into Liquid Glass for a native feel, or hold your own identity? Both are valid, but the decision should be deliberate rather than accidental.

What it means if you build with Flutter

Cross-platform teams do not get Liquid Glass for free the way native UIKit apps do, but the Flutter ecosystem has moved quickly. Recent Flutter releases added full support for the iOS 26 toolchain and introduced Cupertino Squircles — the continuous-curvature rounded corners that match Apple’s native shapes. If your goal is an app that feels at home on iOS 26, staying current on the Cupertino widget set and testing against the latest iOS SDK matters more than it did a year ago.

The pragmatic takeaway: whether you build native or cross-platform, iOS 26 raises the bar for what “feels like an iPhone app” means. Audit your custom UI, re-check contrast on translucent surfaces, and decide consciously how much of Liquid Glass you want to adopt.

The bottom line

iOS 26 is the most visually significant iPhone update in nine years, and Liquid Glass is here to stay. For developers, the work is not dramatic, but it is real: lean on system components where you can, re-test legibility everywhere, and keep your toolchain current. The apps that feel best on iOS 26 will be the ones whose teams treated the redesign as a prompt to revisit their UI — not a problem to ignore.

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

Widget Previews shipped as experimental back in 3.35, and a lot of developers tried it once, found it slow, and went back to hot reload. Flutter 3.47 marks it stable, with local build caching and an abstract theming API that makes the feature worth a second look. If you build design systems, component libraries, or anything with more than three visual states, this changes your inner loop.

The pitch is narrow and honest: the previewer renders individual widgets in isolation, without booting your app, navigating to the right screen, or faking the right state. That is a different job from hot reload, and it is the job hot reload has always been bad at.

Starting the previewer

From your IDE — Android Studio, IntelliJ, or VS Code — the previewer starts automatically; open the Flutter Widget Preview tab in the sidebar. From a terminal:

flutter widget-preview start

That launches a local server and opens a live preview environment in your browser. Builds are cached in a .widget_preview/ folder in your project — this cache is the reason startup got noticeably faster in 3.47, and it is the thing to add to .gitignore if your tooling has not already.

What you can annotate

@Preview comes from package:flutter/widget_previews.dart and can be applied to:

• top-level functions returning a Widget or WidgetBuilder
• static methods in a class returning a Widget or WidgetBuilder
• public widget constructors and factories that take no required arguments

The simplest possible case:

import 'package:flutter/material.dart';
import 'package:flutter/widget_previews.dart';

@Preview(name: 'My Sample Text')
Widget mySampleText() {
  return const Text('Hello, World!');
}

No app, no MaterialApp, no route. Save the file and the preview updates.

Every parameter, and what it is actually for

The Preview class is small, which is a good sign. Here is the full surface:

wrapper is the one that makes previews usable in a real codebase. Most widgets are not standalone — they expect a Scaffold, a theme, or an injected repository. You supply that once:

@Preview(
  name: 'Submit button — pressed state',
  group: 'Form Controls',
  size: Size(240, 56),
  textScaleFactor: 1.5,
  wrapper: _inScaffold,
)
Widget submitButtonPreview() => const SubmitButton(isBusy: true);

Widget _inScaffold(Widget child) => MaterialApp(
      home: Scaffold(body: Center(child: child)),
    );

Rendering the same widget many ways

This is where previews beat hot reload outright. Stack annotations to get one widget rendered under several configurations at once:

@Preview(group: 'Brightness', name: 'Light', brightness: Brightness.light)
@Preview(group: 'Brightness', name: 'Dark', brightness: Brightness.dark)
Widget buttonPreview() => const ButtonShowcase();

When the same three or four variants repeat across dozens of components, promote them to a MultiPreview:

final class MultiBrightnessPreview extends MultiPreview {
  const MultiBrightnessPreview();

  @override
  List<Preview> get previews => const [
        Preview(group: 'Brightness', name: 'Light', brightness: Brightness.light),
        Preview(group: 'Brightness', name: 'Dark', brightness: Brightness.dark),
      ];
}

@MultiBrightnessPreview()
Widget buttonPreview() => const ButtonShowcase();

Baking your design system into a custom annotation

The abstract theme API added in 3.47 is the piece that makes this scale. Rather than repeating theme: on every preview, subclass Preview and supply the builder once:

final class MyCustomPreview extends Preview {
  const MyCustomPreview({
    super.name,
    super.group,
    super.size,
    super.textScaleFactor,
    super.wrapper,
    super.brightness,
    super.localizations,
  }) : super(theme: MyCustomPreview.themeBuilder);

  static PreviewThemeData themeBuilder() {
    return PreviewThemeData(
      materialLight: ThemeData.light(),
      materialDark: ThemeData.dark(),
    );
  }
}

Now every @MyCustomPreview(...) in the codebase renders against your real tokens. PreviewThemeData carries both Material and Cupertino data, which matters more in 3.47 than it used to — with the design system moving into standalone material_ui and cupertino_ui packages, previews are a cheap way to see whether a component actually survives both.

There is also transform(), which lets a custom annotation rewrite the preview at runtime — useful for prefixing names or swapping themes across a whole class of previews without touching call sites.

Previews are not golden tests

Worth being blunt about this, because teams confuse the two. Previews are an authoring tool: fast, visual, human-in-the-loop, no assertions. Golden tests are a regression tool: slow, headless, and they fail your CI when a pixel moves. Previews do not replace goldens, and a preview passing means nothing except that it rendered.

The useful pairing is previews while you build the component, goldens once its states are settled.

The limitations you will hit

The previewer runs in a web-based environment, which sets hard boundaries:

1. No native plugins, and no dart:io or dart:ffi. Anything touching the filesystem, platform channels, or FFI will not render — inject a fake through wrapper instead.
2. Callback arguments must be public and constant. Private closures will not be picked up.
3. Asset paths must be package-based: use 'packages/my_package_name/assets/my_image.png', not 'assets/my_image.png'.
4. Unconstrained widgets are automatically clamped to roughly 50% of the previewer’s height and width. Pass size when that squashes your layout.
5. Single project or Pub workspace only. Multi-project IDE support is still being investigated, so a large monorepo may not light up entirely.

Adopting it without a rewrite

1. Upgrade to 3.47 and run flutter widget-preview start once to confirm the previewer builds your project.
2. Add .widget_preview/ to .gitignore.
3. Pick one leaf component — a button, a badge, a list tile — and add a single @Preview. Do not start with a screen.
4. Write one wrapper that installs your app’s theme and providers, and reuse it.
5. Promote your recurring variants (light/dark, text scale 1.0/2.0, LTR/RTL) into a MultiPreview.
6. Subclass Preview with your design system’s PreviewThemeData and standardise on that annotation.
7. Add goldens for the states you now know are correct.

The bottom line

Widget Previews stopped being a demo in 3.47. The caching makes startup tolerable, and the theme APIs are the difference between a toy and something a design-system team can standardise on. The limitations are real — no native code, package-based asset paths, single-workspace — but they are limitations of scope, not of maturity. If you tried previews in 3.35 and shrugged, the honest advice is to try again: this is the release where the feature earns its place in the loop.

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

WebAssembly is the largest single bet in Flutter’s 2026 roadmap, and 3.47 moves it forward again with experimental deferred loading. The Q2 2026 survey rates Web at 72% satisfaction — the second-lowest platform score — and load performance is a big part of why. Wasm is the intended fix.

But shipping Wasm today is not a flag. It is a migration, a browser support matrix with a large hole in it, and two HTTP headers that most people forget.

The build commands

# Development
flutter run -d chrome --wasm

# Production
flutter build web --wasm

# Production, with symbolication for error monitoring
flutter build web --wasm --source-maps

# Staging/QA — readable stack traces, ~47% larger binary
flutter build web --wasm --no-strip-wasm

Use --source-maps for anything you point Sentry or a similar service at; it produces main.dart.wasm.map. Use --no-strip-wasm only in staging — the size cost is real.

Flutter 3.47 also adds experimental deferred loading:

flutter build web --release --wasm --enable-wasm-deferred-loading

At the Dart layer this is the same capability that landed as a preview in Dart 3.13 (dart compile wasm -O2 --enable-deferred-loading), reported to give meaningful initial-page-load improvements over dart2js for large applications. For a big app this is the difference between Wasm being theoretically faster and actually faster in the metric users feel.

The browser matrix, and the iOS problem

Flutter’s Wasm output needs WasmGC. Support today:

Read the last row again. It is not “Safari on iOS”; it is all browsers on iOS, because Apple requires WebKit. If your web traffic skews mobile, a meaningful share of your users will not execute your Wasm build at all.

Which is why the fallback matters: even with --wasm, Flutter still compiles to JavaScript. If WasmGC is not detected at runtime, the JS build runs. You are shipping both, and the browser picks. That is good for correctness and bad for anyone hoping Wasm reduces their deployment size.

To confirm which path a session took:

const isRunningWithWasm = bool.fromEnvironment('dart.tool.dart2wasm');

Log it. Otherwise you will be optimising a code path most of your users never hit.

The actual migration: get off dart:html

This is the work. Wasm will not compile if your app imports unsupported web libraries.

Flutter gives you an early warning without needing a Wasm build at all — running plain flutter build web performs a Wasm dry run:

Wasm dry run failed:
Found incompatibilities with WebAssembly.

package:my_app/main.dart 1:1 - dart:html unsupported (0)

Run that today, even if you have no Wasm plans. It is a free audit of your dependency tree.

When a full compilation fails, ignore the stack trace and find the Context tree — it names the package chain that pulled in the incompatible library:

Context: The unavailable library 'dart:html' is imported through these packages:
    main.dart => package:my_app => dart:html

That is usually a transitive dependency, not your code. For a gradual migration, conditional imports let both worlds coexist:

import 'fallback.dart'
  if (dart.library.js) 'legacy_web_interop.dart'
  if (dart.library.js_interop) 'wasm_web_interop.dart';

The two headers everyone forgets

Flutter Wasm apps can render across multiple threads — but only if your server sends the right cross-origin headers:

Without both, multi-threading silently does not happen. Your app works; it is just slower than the benchmark you read. Check them in your CDN or reverse proxy config, not just in local dev — this is a classic “fast on localhost, slow in production” trap.

Note that require-corp will break embedded third-party resources that do not opt in via CORP headers. If you embed a lot of external content, credentialless is usually the pragmatic choice.

Runtime differences worth knowing

package:web and dart:js_interop under Wasm are not bit-identical to the JS backend:

• is / as checks behave differently on JS interop types
• Zone propagation in callbacks differs

Neither breaks a typical app, but both will bite code that does clever things with type checks across the interop boundary. Test your interop layer specifically rather than assuming parity.

Your rollout plan

1. Run flutter build web today and read the Wasm dry run output. That is your migration backlog.
2. Update web/index.html to the current Flutter initialization, or regenerate with flutter create . --platforms web.
3. Migrate your own code from dart:html to package:web and from dart:js to dart:js_interop.
4. Chase the transitive offenders named in the Context tree. File issues on dependencies that still import dart:html.
5. Configure COOP and COEP headers in your production serving layer, then verify them with the network tab.
6. Build with --wasm --source-maps and wire the map file into your error monitoring.
7. Log dart.tool.dart2wasm and measure what fraction of real sessions actually get the Wasm path.
8. Try --enable-wasm-deferred-loading if your bundle is large, and measure initial page load rather than total size.

The bottom line

Wasm is genuinely faster, and the roadmap points at it becoming the default. But today it is an additive build, not a replacement: you ship JS as well, iOS users get the JS path regardless, and the performance win depends on two headers most teams have not set. The single highest-value thing you can do this week costs nothing — run flutter build web and read the dry-run output. Whether or not you ship Wasm this quarter, that list of dart:html dependencies is a debt you will pay eventually.

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

Most Flutter migrations are optional until they are annoying. This one is different: once Apple enforces the requirement, apps that have not adopted the UIScene lifecycle will crash on startup. Not degrade. Crash.

Apple requires UIKit apps built with the latest SDK to use the UIScene lifecycle starting in the release following iOS 26. Apple has not announced the exact enforcement date. Flutter has supported the migration since 3.38, and 3.47 makes the surrounding platform changes concrete by raising the floors: iOS 13 → 15 and macOS 10.15 → 12, to support Xcode 27.

What UIScene actually changes

The conceptual shift is a split of responsibilities that used to live in one object:

• AppDelegate now handles process events and overall application lifecycle
• UISceneDelegate handles UI lifecycle — foreground, background, active, resign

Two consequences follow, and both break code:

1. Plugin registration moves. Register in didInitializeImplicitFlutterEngine, not application:didFinishLaunchingWithOptions:.
2. Launch options become nil in application:didFinishLaunchingWithOptions: after migration. They are delivered to scene:willConnectToSession:options: instead.

That second one is the silent killer. Deep links, push notification payloads, and shortcut items that arrived through launch options simply stop arriving, with no compile error.

The good news: it is often automatic

As of Flutter 3.41, if your AppDelegate has not been customised, the Flutter CLI migrates your app automatically when you run flutter run or flutter build ios. A large fraction of apps are already done and did not notice.

You have work to do if you customised AppDelegate, ship an add-to-app integration, or maintain a plugin.

Info.plist

The migration adds an Application Scene Manifest:

<key>UIApplicationSceneManifest</key>
<dict>
  <key>UIApplicationSupportsMultipleScenes</key>
  <false/>
  <key>UISceneConfigurations</key>
  <dict>
    <key>UIWindowSceneSessionRoleApplication</key>
    <array>
      <dict>
        <key>UISceneClassName</key>
        <string>UIWindowScene</string>
        <key>UISceneDelegateClassName</key>
        <string>FlutterSceneDelegate</string>
        <key>UISceneConfigurationName</key>
        <string>flutter</string>
        <key>UISceneStoryboardFile</key>
        <string>Main</string>
      </dict>
    </array>
  </dict>
</dict>

A useful debugging trick: prefix UIApplicationSceneManifest with an underscore to temporarily disable UIScene support, and remove the underscore to re-enable. That gives you a fast A/B when something breaks.

AppDelegate

Move plugin registration out of didFinishLaunchingWithOptions and into the new delegate callback:

@objc class AppDelegate: FlutterAppDelegate, FlutterImplicitEngineDelegate {
  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    // GeneratedPluginRegistrant no longer belongs here
    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }

  func didInitializeImplicitFlutterEngine(_ engineBridge: FlutterImplicitEngineBridge) {
    GeneratedPluginRegistrant.register(with: engineBridge.pluginRegistry)

    let batteryChannel = FlutterMethodChannel(
      name: "samples.flutter.dev/battery",
      binaryMessenger: engineBridge.applicationRegistrar.messenger()
    )
  }
}

Method channels and platform view factories both need the messenger from engineBridge.applicationRegistrar, not the old application-level one.

For add-to-app, add a scene delegate — usually a one-liner:

import UIKit
import Flutter

class SceneDelegate: FlutterSceneDelegate {}

If your host app cannot subclass FlutterSceneDelegate, implement FlutterSceneLifeCycleProvider and forward each scene callback to a FlutterPluginSceneLifeCycleDelegate instance.

If you maintain a plugin

Plugin authors carry the heaviest load, because every app depending on you inherits your migration state.

Bump your constraints, then adopt the protocol and register for scene callbacks:

environment:
  sdk: ^3.10.0
  flutter: ">=3.38.0"

public final class MyPlugin: NSObject, FlutterPlugin, FlutterSceneLifeCycleDelegate {
  public static func register(with registrar: FlutterPluginRegistrar) {
    registrar.addApplicationDelegate(instance)
    registrar.addSceneDelegate(instance)
  }
}

Then map your old callbacks:

The APIs that stop working

A set of long-standing UIKit singletons are deprecated under the scene model. Each has a scene-scoped replacement:

Note that UIWindowScene.keyWindow requires iOS 15 — which is exactly the floor Flutter 3.47 just raised you to. The two changes are related, not coincidental.

The genuinely hard case: early initialisation

Some Apple APIs must be configured before application:didFinishLaunchingWithOptions: returns — BGTaskScheduler, UNUserNotificationCenterDelegate, HKHealthStore. Under the scene model, plugin registration happens later than that.

There is no way for a plugin to solve this alone. The documented pattern is for the plugin to expose a public method that the app developer calls from their own AppDelegate:

class AppDelegate: FlutterAppDelegate {
  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    BGTaskPlugin.shared.registerBackgroundHandler(identifier: "com.example.task")
    return super.application(application, didFinishLaunchingWithOptions: launchOptions)
  }
}

If you use background tasks, health data, or notification delegates, check your plugin’s docs for exactly this pattern. It is the migration step most likely to be missed and least likely to be caught by a test.

Your migration checklist

1. Build on 3.47 and let the automatic migration run if your AppDelegate is stock.
2. Add the UIApplicationSceneManifest to Info.plist if it is not there.
3. Move GeneratedPluginRegistrant into didInitializeImplicitFlutterEngine, along with method channels and platform view factories.
4. Re-test every entry point: deep links, universal links, push notification taps, home-screen quick actions. Launch options are nil now.
5. Grep for the deprecated singletons — UIScreen.main, keyWindow, UIApplication.shared.windows — in your code and your plugins.
6. Raise deployment targets to iOS 15 and macOS 12, then run flutter build ios --config-only.
7. Check plugins that need early init and add the required call in your AppDelegate.
8. Do not use enable-uiscene-migration: false as anything other than a short-term unblock — it hides the warning, not the eventual crash.

The bottom line

This is the one migration in Flutter 3.47 with a hard failure mode. The mechanical parts are well documented and largely automated, so most apps will pass with a rebuild. The parts that will actually bite are the untested paths: a deep link that no longer carries its payload, a plugin that registers a background task too late, a keyWindow call buried in a dependency. Do the rebuild today, then spend an hour opening your app from every external entry point you support. That hour is much cheaper than a launch-day crash report.

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

Most Flutter developers have already migrated to Swift Package Manager without noticing. It has been enabled by default since Flutter 3.44, and the tooling adds the integration to your Xcode project the first time you build after upgrading. The reason to pay attention now is a date: the CocoaPods registry becomes read-only on December 2, 2026. After that, opting out stops being a supported escape hatch.

Flutter 3.47 reports that 92 of the top 100 iOS plugins have migrated to Swift Package Manager. The long tail is what will bite you, not the head of the distribution.

What actually changes in your project

When SwiftPM is enabled and you build, Flutter modifies your Xcode project in three ways:

1. Adds FlutterGeneratedPluginSwiftPackage as a package dependency of the Runner target.
2. Adds a Run Prepare Flutter Framework Script pre-action to your build scheme.
3. Resolves and downloads the Swift packages your Flutter plugins depend on.

That generated package lives at ios/Flutter/ephemeral/Packages/FlutterGeneratedPluginSwiftPackage. The word ephemeral is doing real work there — it is regenerated, not hand-edited, and it does not belong in version control.

Crucially, CocoaPods does not disappear. Flutter falls back to CocoaPods automatically for any dependency that does not yet support SwiftPM, so a mixed project is the normal state during the transition, not a misconfiguration.

Turning it on, off, and per-project

If a previous version of your project disabled it, re-enable globally:

flutter config --enable-swift-package-manager

To disable globally:

flutter config --no-enable-swift-package-manager

To disable for one project only, in pubspec.yaml:

flutter:
  config:
    enable-swift-package-manager: false

The per-project switch is the useful one. If exactly one app in your organisation depends on an unmigrated internal plugin, pin that app and leave everything else on the default.

Removing the integration entirely

If you need a clean rollback — for a bisect, or because a build broke and you want a known-good baseline:

1. Turn SwiftPM off using one of the switches above.
2. Run flutter clean.
3. Open your Xcode workspace.
4. Remove FlutterGeneratedPluginSwiftPackage from Package Dependencies.
5. Remove it from Frameworks, Libraries, and Embedded Content.
6. Delete the Run Prepare Flutter Framework Script pre-action.

Steps 3 through 6 are the ones people forget, and a half-removed integration produces confusing link errors.

When automatic migration fails

The tooling occasionally cannot patch an Xcode project — heavily customised schemes and hand-edited project.pbxproj files are the usual culprits. The manual path:

Add the package dependency. Open ios/Runner.xcworkspace, go to Package Dependencies, click add, choose Add Local…, and select ios/Flutter/ephemeral/Packages/FlutterGeneratedPluginSwiftPackage. Confirm it is attached to the Runner target and appears under Frameworks, Libraries, and Embedded Content.

Add the pre-action. Go to Product → Scheme → Edit Scheme, expand Build, click Pre-actions, add a run script action titled Run Prepare Flutter Framework Script, set Provide build settings from to Runner, and use:

"$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" prepare

Then run the app and confirm the pre-action executes. If automatic migration failed, file a bug with your project.pbxproj and .xcscheme attached — that is the data the Flutter team needs and rarely gets.

The deployment target trap

This is the most common real-world failure, and it is not obvious from the error message. A SwiftPM plugin can declare a higher minimum OS version than your app. When it does, the build fails until you raise Minimum Deployments in Xcode and regenerate the config:

flutter build ios --config-only
flutter build macos --config-only

Flutter 3.47 already raised the floors — iOS 13 → 15 and macOS 10.15 → 12 — so if you are upgrading from an older SDK you may clear this hurdle by accident.

Your migration checklist

1. Confirm you are on the default. Run flutter config and check that enable-swift-package-manager is not disabled anywhere, including pubspec.yaml.
2. Build a clean iOS and macOS target and watch for the pre-action running.
3. Audit your plugin list. For each iOS plugin, check whether its repository ships a Package.swift. The ones that do not are your December risk.
4. Migrate your own plugins first — internal plugins are the ones nobody else will fix for you. Follow the plugin-author guide and ship a Package.swift alongside the existing podspec.
5. File or upvote issues on the unmigrated third-party plugins you depend on, now rather than in November.
6. Raise deployment targets to iOS 15 / macOS 12 and regenerate with --config-only.
7. Do not add ios/Flutter/ephemeral/ to version control.

The bottom line

SwiftPM is not a feature you need to adopt — you almost certainly already have. What you need to do is inventory the plugins that have not, because December 2, 2026 turns “we’ll handle it later” into a build break. The head of the ecosystem is done: 92 of the top 100 plugins have moved. Spend an hour on the tail — your internal plugins and the three obscure packages nobody has looked at since 2024 — and this transition costs you nothing at all.

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

Multi-window is the oldest item on the Flutter desktop wishlist. A desktop app that cannot open a second window is not really a desktop app — no detached inspector, no tear-off panel, no floating tool palette, no proper context menu that escapes the main window’s bounds.

Flutter 3.41 shipped experimental multi-window APIs for desktop. Flutter 3.47 fills in a large amount of the plumbing underneath them. What it does not do is make them stable, and being clear about that distinction will save you a painful quarter.

What actually landed in 3.47

The desktop work in this release is mostly engine-level, and it is substantial:

Popup windows. Win32 and Linux both got popup window implementations. This is the foundation for menus, tooltips, and dropdowns that render outside the parent window’s bounds — a category of UI that Flutter desktop has faked with overlays until now.

Sized-to-content windows. Regular and dialog windows can now size themselves to their content on Win32, and the decorated flag was removed from the windowing API in the process. A dialog that is exactly as tall as its text is a small thing that makes an app feel native.

An API rename. preferredSize became size, and preferredConstraints became constraints. If you have been tracking the experimental API on main, this one will break your code, and the rename is a signal in itself: the team is tidying the surface, which usually precedes stabilisation.

Platform handles are now exposed. The multi-window API can hand you platform-specific window handles — the escape hatch you need for native integration that Flutter does not model.

A public API to post tasks to the platform thread on Windows. Unglamorous, and necessary for anything that has to touch Win32 from Dart.

--flavor support for Windows and Linux desktop builds. Long overdue. Multiple build flavors — dev, staging, production — finally work on desktop the way they do on mobile.

The status you need to internalise

The Flutter team’s own framing on the tracking issue is explicit. The multi-window APIs are experimental, and the stated goals are to build confidence by letting customers dogfood them on Flutter’s main release channel, while retaining the ability to change them.

Both halves of that sentence matter:

• Main channel, not stable. You are not getting these APIs on the stable release you ship from.
• Ability to change them. The preferredSize → size rename in this very release is proof that they mean it.

So what do you actually use today

If you need multi-window in a production app on the stable channel, the answer is still a community package — desktop_multi_window being the most established of them. It creates additional native windows and runs a separate Flutter engine instance in each, with a message channel between them.

That architecture has a consequence worth understanding before you adopt it: each window is a separate engine, so they do not share Dart state. Your Provider, your Bloc, your singletons — none of them cross the window boundary. Everything is message passing:

// Conceptually: each window runs its own engine and entry point.
// Shared state must be serialised across a channel, not read directly.
void main(List<String> args) {
  if (args.firstOrNull == 'multi_window') {
    // Secondary window entry point — separate isolate, separate state.
    runApp(const SecondaryWindowApp());
    return;
  }
  runApp(const MainApp());
}

Design for that from the start. Teams that bolt multi-window onto an app with a single global store spend most of their time reimplementing state synchronisation.

The experimental framework API takes a different approach — multiple windows within one engine — which is why it is the better long-term answer and why it is taking time to get right.

Where desktop stands more broadly

Some context from the Q2 2026 survey: Windows satisfaction is 74%, Linux is 73% — the lowest platform scores after Cupertino. The top developer pain point overall is platform and ecosystem maturity at 44%.

Multi-window is a big part of why. Flutter desktop has been production-capable for years, but the gap between “works” and “feels native” has been filled with missing window management primitives. The 3.47 changes — popup windows, sized-to-content, flavors — are unglamorous and directly target that gap.

A practical plan

1. If you ship on stable today, use a community multi-window package and design for message passing between engines from day one.
2. If you are tracking main, adopt the experimental API now and expect to fix renames each release. The preferredSize → size change is a template for what is coming.
3. Adopt --flavor on Windows and Linux immediately. This one is not experimental and it is a straightforward win for your build pipeline.
4. Audit your overlay-based menus and tooltips. Once popup windows are available on your channel, anything that currently clips at the window edge can be fixed properly.
5. Do not architect around shared global state across windows. Serialise, or you will rewrite it.
6. Test window behaviour on multi-monitor setups with mixed DPI. This is where desktop window bugs actually live.
7. File bugs against the experimental API. Dogfooding is the stated purpose; feedback now shapes what stabilises.

The bottom line

Flutter 3.47 is a serious desktop release even though the headline feature list barely mentions desktop. Popup windows on two platforms, sized-to-content windows, exposed platform handles, and flavor support are exactly the unexciting primitives that separate a port from a native-feeling application. The multi-window API itself is still experimental and still main-channel, so ship with a package for now — but the direction is unambiguous, and the API rename in this release suggests the team is cleaning up ahead of stabilisation rather than still exploring.

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

For nine years, import 'package:flutter/material.dart'; has been the first line of almost every Flutter file ever written. Flutter 3.47 begins ending that. material_ui and cupertino_ui are now standalone packages on pub.dev, both at 1.0, both published by the verified flutter.dev publisher. The copies inside the SDK still work — and are scheduled for formal deprecation in the November stable release.

This is a bigger change than the diff suggests, so it is worth understanding the reasoning before you run the migration tool.

Why decouple at all

The Q2 2026 survey answers this more clearly than any blog post. Across every focus area, satisfaction is high: Dart at 92%, Android at 91%, the core framework at 90%. One number breaks the pattern — Cupertino widgets at 61%, down 6 points, the lowest-rated area in the survey.

The structural cause is release cadence. Bound to the SDK, Cupertino could only ship fixes on the quarterly stable train. Apple ships design changes whenever it likes. A design system that can only respond four times a year will always trail the platform it is imitating.

Unbundled, material_ui and cupertino_ui can release weekly. That is the whole strategy: not a refactor for elegance, but a fix for a cadence mismatch that shows up directly in developer satisfaction.

The second benefit is version independence. Today, upgrading Flutter means accepting every widget change at the same time. Once the design system is a normal dependency, you can pin it:

dependencies:
  flutter:
    sdk: flutter
  material_ui: ^1.0.0
  cupertino_ui: ^1.0.0

Upgrade the framework for an engine fix without inheriting a ListTile layout change in the same afternoon.

What actually changes in your code

The import path, mostly:

Widget APIs are unchanged. This is a packaging move, not an API break — which is exactly why it can be automated.

Running the migration

Add the packages, then let dart fix rewrite the imports:

flutter pub add material_ui cupertino_ui
dart fix --apply --code=migrate_design_widgets

The migrate_design_widgets fix rewrites imports from the old framework location to the new packages across your project. Review the diff — it should be almost entirely import lines. Anything else is worth a second look.

The one thing the fix does not fully handle for you is localizations. If you use GlobalMaterialLocalizations, move to the version material_ui provides rather than the one from flutter_localizations. Mixing them produces confusing “no localizations found” failures at runtime rather than compile time, so grep for it explicitly:

grep -rn "GlobalMaterialLocalizations" lib/

Surviving the mixed-dependency phase

Here is the realistic problem. You migrate your app in twenty minutes. Then you discover that four of your dependencies still import package:flutter/material.dart, and their widget trees and yours now come from different libraries.

That is what MaterialUiCompatibilityBridge exists for. Wrap your app — or just the subtree containing the legacy widgets — and the old and new trees interoperate:

import 'package:material_ui/material_ui.dart';

void main() {
  runApp(
    MaterialUiCompatibilityBridge(
      child: const MyApp(),
    ),
  );
}

Treat the bridge as scaffolding with a demolition date, not architecture. Every wrapped subtree is a dependency you are waiting on. Keep a list.

The deprecation timeline

Nothing breaks today. The sequence to plan around:

• Now (3.47): both paths work. Packages are at 1.0. Migration is opt-in.
• November stable: the SDK’s Material and Cupertino libraries are formally deprecated. Expect analyzer warnings on every unmigrated import.
• Later: deprecated APIs eventually get removed. No date has been announced, and you should not wait for one.

The honest cost estimate is an afternoon for an app, longer for a plugin ecosystem you do not control.

If you ship a package

Package authors carry the real burden here, because your choice propagates to every consumer. A few rules of thumb:

• Do not migrate and immediately publish a breaking major if your package only touches a handful of widgets — you will fragment your users across two worlds for no benefit.
• Do migrate promptly if your package is a UI library. Your users cannot finish their migration until you finish yours.
• Widen your constraints rather than pinning tightly, so consumers can pick up design-system fixes without waiting for your release.

Your migration checklist

1. Upgrade to Flutter 3.47 and confirm a clean build before changing anything.
2. Run flutter pub add material_ui cupertino_ui.
3. Run dart fix --apply --code=migrate_design_widgets and read the diff.
4. Search for GlobalMaterialLocalizations and switch it to the material_ui version.
5. Build and run on at least one iOS and one Android target. Watch for theme and localization regressions specifically.
6. Identify dependencies still on the SDK libraries. File issues on them today.
7. Wrap with MaterialUiCompatibilityBridge only where you must, and record why.
8. Set a calendar reminder for October to re-check the list before the November deprecation lands.

The bottom line

This migration is mechanical, and the tooling does most of it. The part that needs judgement is the dependency graph: your app is easy, your dependencies are not, and MaterialUiCompatibilityBridge is a bridge rather than a destination. Do the mechanical part now while it is optional and the analyzer is quiet — it is a much less pleasant task in November, with warnings on every file and a deprecation clock running.

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