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.

Apple is reportedly about to do something it has not done in the modern iPhone era: split its flagship lineup across two seasons. According to widely reported supply-chain and analyst accounts, fall 2026 will bring the iPhone 18 Pro, iPhone 18 Pro Max, and Apple’s first foldable iPhone, while the standard iPhone 18, an iPhone 18e, and possibly an iPhone Air 2 slide to a spring 2027 launch. As always with unreleased hardware, treat the specifics as rumor — but the direction is consistent across sources.

The first foldable iPhone

The most significant part of this story is the foldable iPhone, often called the “iPhone Fold.” Reports point to roughly a 5.4-inch display when closed and around a 7.8-inch display when open, with a “nearly invisible” crease thanks to a high-quality hinge. Pricing is rumored to start near $2,500, positioning it as a halo device rather than a mainstream one.

If accurate, this matters far beyond Apple’s lineup. A foldable from Apple would validate the form factor for a huge base of iOS users and developers who have so far treated folding phones as an Android curiosity. Overnight, “does your app work unfolded?” becomes a question iOS teams have to answer too.

iPhone 18 Pro: incremental but pointed

The iPhone 18 Pro is expected to be a refinement of the well-reviewed 17 Pro. Rumored changes include a slimmed-down Dynamic Island — possibly enabled by under-display Face ID, leaving just a single front-camera cutout in the top-left corner — an upgraded variable-aperture Wide camera, and a faster 2nm A20 chip. A new deep-red finish is rumored to be the year’s signature color.

Under-display Face ID and a shrinking Dynamic Island are the kind of change that ripples into app design: safe-area insets and notch-aware layouts have to adapt whenever Apple changes the top of the screen.

What developers should take away

• Foldable readiness is now cross-platform. If Apple ships a folding iPhone, responsive and adaptive layouts stop being an Android-only concern. Building with a framework that handles variable screen geometry well — Flutter among them — becomes a hedge.
• Watch the safe areas. A smaller Dynamic Island and under-display sensors will change top-of-screen insets. Layouts that hard-code notch dimensions will break.
• Plan for a longer iPhone season. A split launch calendar means “the new iPhone” is no longer a single fall moment. Testing and release planning may need to span more of the year.

The bottom line

Fall 2026 could be the most strategically important iPhone launch in years — not because the iPhone 18 Pro is revolutionary, but because a foldable iPhone and a split launch calendar would reshape how developers think about screen size, safe areas, and release timing. Nothing is official until Apple says so, but teams that build adaptive, folding-friendly UI now will be ready either way.

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

The iPhone 17 Pro, which Apple released in September 2025 starting at $1,099, is now the device most demanding iPhone users carry — and the reference target most mobile developers should be testing against. Nearly a year on, it is a clearer story than it looked at launch: a thermal and performance rethink wrapped in a material Apple abandoned two generations ago.

Aluminum is back — and it is the point

The headline hardware change is that Apple moved the Pro back to an aluminum unibody, away from the titanium of recent years. That sounds like a step down until you understand why: aluminum is lighter than titanium and disperses heat better. Apple laser-welded a vapor chamber into that aluminum frame, and the result is what the company calls its best-ever sustained performance and “an enormous leap in battery life.”

For anyone who has watched an iPhone throttle during a long export, a heavy game, or an on-device AI task, this is the meaningful change. Peak benchmarks matter less than sustained ones, and sustained performance is exactly what better cooling buys.

The A19 Pro and on-device AI

Both Pro models run the A19 Pro, which Apple calls its most powerful and efficient iPhone chip yet. In 2026 the interesting workload is not just gaming — it is Apple Intelligence and on-device AI. A chip that can hold its clocks under thermal load is a chip that can run local models without the device turning into a hand warmer. For developers experimenting with on-device inference, the 17 Pro is the phone that makes those features feel viable rather than demo-only.

Cameras: three 48MP sensors and an 8x zoom

The camera system is three 48MP Fusion cameras — Main, Ultra Wide, and an all-new Telephoto — which Apple says delivers the equivalent of eight lenses. The telephoto uses a next-generation tetraprism design with a 56% larger sensor and an equivalent 200mm focal length, giving an 8x optical-quality zoom and a 16x total optical range. It is the longest telephoto ever on an iPhone.

Durability improved too: Ceramic Shield 2 on the front offers 3x better scratch resistance, and for the first time Ceramic Shield protects the back of the phone as well.

Why it matters for app builders

• Test on the current Pro. Its display, cameras, and thermal profile define the “high end” your app is judged against.
• Design for sustained performance. The 17 Pro’s cooling means users expect heavy features — AR, video, on-device AI — to run without slowdowns.
• Camera-heavy apps have more to work with. The 8x telephoto and 48MP sensors open real product opportunities for photography, scanning, and AR apps.

The bottom line

The iPhone 17 Pro is not a flashy redesign; it is a re-engineering. The aluminum-and-vapor-chamber body fixes the thermal ceiling that limited sustained performance, the A19 Pro makes on-device AI practical, and the camera system is a genuine leap for anyone building with the lens. If you build for iPhone, this is the device to target — and a preview of where Apple is heading with the iPhone 18 Pro later in 2026.

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.

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.