Flutter - free resource mobile app, desktop, web

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.

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.

Phần lớn các cuộc migrate trong Flutter là tuỳ chọn cho tới khi chúng gây phiền. Cái này khác: khi Apple bắt đầu cưỡng chế, app chưa áp dụng vòng đời UIScene sẽ crash ngay lúc khởi động. Không phải giảm chất lượng. Là crash.

Apple yêu cầu app UIKit build bằng SDK mới nhất phải dùng vòng đời UIScene kể từ bản phát hành sau iOS 26. Apple chưa công bố ngày cưỡng chế chính xác. Flutter đã hỗ trợ migrate từ 3.38, và 3.47 làm các thay đổi nền tảng xung quanh trở nên cụ thể bằng cách nâng sàn: iOS 13 → 15 và macOS 10.15 → 12, để hỗ trợ Xcode 27.

UIScene thực sự thay đổi điều gì

Sự dịch chuyển về khái niệm là việc tách trách nhiệm vốn nằm trong một đối tượng:

• AppDelegate giờ xử lý sự kiện tiến trình và vòng đời tổng thể của ứng dụng
• UISceneDelegate xử lý vòng đời UI — foreground, background, active, resign

Hai hệ quả đi kèm, và cả hai đều làm hỏng code:

1. Đăng ký plugin dời chỗ. Đăng ký trong didInitializeImplicitFlutterEngine, không phải application:didFinishLaunchingWithOptions:.
2. Launch options trở thành nil trong application:didFinishLaunchingWithOptions: sau khi migrate. Chúng được chuyển tới scene:willConnectToSession:options:.

Cái thứ hai mới là sát thủ thầm lặng. Deep link, payload push notification, và shortcut item vốn đến qua launch options đơn giản là ngừng đến, không có lỗi biên dịch nào.

Tin tốt: thường là tự động

Từ Flutter 3.41, nếu AppDelegate của bạn chưa bị tuỳ biến, Flutter CLI tự migrate app khi bạn chạy flutter run hoặc flutter build ios. Một phần lớn app đã xong mà không hề hay biết.

Bạn có việc phải làm nếu bạn đã tuỳ biến AppDelegate, ship một tích hợp add-to-app, hoặc duy trì một plugin.

Info.plist

Cuộc migrate thêm một 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>

Một mẹo debug hữu ích: thêm dấu gạch dưới vào trước UIApplicationSceneManifest để tạm tắt hỗ trợ UIScene, và bỏ dấu gạch dưới để bật lại. Điều đó cho bạn một phép so sánh A/B nhanh khi có gì đó hỏng.

AppDelegate

Chuyển việc đăng ký plugin ra khỏi didFinishLaunchingWithOptions và vào callback mới:

@objc class AppDelegate: FlutterAppDelegate, FlutterImplicitEngineDelegate {
  override func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    // GeneratedPluginRegistrant không còn thuộc về đây
    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 channel và platform view factory đều cần messenger từ engineBridge.applicationRegistrar, không phải cái ở cấp application cũ.

Với add-to-app, hãy thêm một scene delegate — thường chỉ một dòng:

import UIKit
import Flutter

class SceneDelegate: FlutterSceneDelegate {}

Nếu app chủ của bạn không kế thừa được FlutterSceneDelegate, hãy cài đặt FlutterSceneLifeCycleProvider và chuyển tiếp từng callback scene tới một instance FlutterPluginSceneLifeCycleDelegate.

Nếu bạn duy trì một plugin

Tác giả plugin gánh phần nặng nhất, vì mọi app phụ thuộc vào bạn đều thừa hưởng trạng thái migrate của bạn.

Nâng ràng buộc, rồi áp dụng protocol và đăng ký nhận callback scene:

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)
  }
}

Rồi ánh xạ các callback cũ:

Những API ngừng hoạt động

Một loạt singleton UIKit lâu đời bị deprecate dưới mô hình scene. Mỗi cái có bản thay thế theo phạm vi scene:

Lưu ý UIWindowScene.keyWindow cần iOS 15 — đúng bằng cái sàn Flutter 3.47 vừa nâng bạn lên. Hai thay đổi này liên quan tới nhau, không phải trùng hợp.

Trường hợp thật sự khó: khởi tạo sớm

Một số API của Apple phải được cấu hình trước khi application:didFinishLaunchingWithOptions: trả về — BGTaskScheduler, UNUserNotificationCenterDelegate, HKHealthStore. Dưới mô hình scene, việc đăng ký plugin xảy ra muộn hơn thời điểm đó.

Không có cách nào để plugin tự giải quyết một mình. Mẫu được tài liệu hoá là plugin phơi ra một method public để lập trình viên app gọi từ AppDelegate của chính họ:

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)
  }
}

Nếu bạn dùng background task, dữ liệu sức khoẻ, hay notification delegate, hãy kiểm tra tài liệu plugin đúng theo mẫu này. Đây là bước migrate dễ bị bỏ sót nhất và ít có khả năng bị test bắt được nhất.

Checklist migrate của bạn

1. Build trên 3.47 và để migrate tự động chạy nếu AppDelegate của bạn còn nguyên bản.
2. Thêm UIApplicationSceneManifest vào Info.plist nếu chưa có.
3. Chuyển GeneratedPluginRegistrant vào didInitializeImplicitFlutterEngine, cùng với method channel và platform view factory.
4. Test lại mọi lối vào: deep link, universal link, chạm vào push notification, quick action ở màn hình chính. Launch options giờ là nil.
5. Grep các singleton bị deprecate — UIScreen.main, keyWindow, UIApplication.shared.windows — trong code của bạn và trong plugin.
6. Nâng deployment target lên iOS 15 và macOS 12, rồi chạy flutter build ios --config-only.
7. Kiểm tra các plugin cần khởi tạo sớm và thêm lời gọi bắt buộc trong AppDelegate của bạn.
8. Đừng dùng enable-uiscene-migration: false như gì khác ngoài một cách gỡ kẹt ngắn hạn — nó giấu cảnh báo, không giấu cú crash sẽ tới.

Kết luận

Đây là cuộc migrate duy nhất trong Flutter 3.47 có chế độ hỏng dứt khoát. Các phần cơ học được tài liệu hoá tốt và phần lớn đã tự động, nên hầu hết app sẽ qua chỉ bằng một lần build lại. Thứ thực sự cắn bạn là những đường chưa được test: một deep link không còn mang theo payload, một plugin đăng ký background task quá muộn, một lời gọi keyWindow chôn trong dependency. Hãy build lại ngay hôm nay, rồi bỏ một giờ mở app của bạn từ mọi lối vào bên ngoài mà bạn hỗ trợ. Một giờ đó rẻ hơn nhiều so với một báo cáo crash vào ngày phát hành.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.

Suốt chín năm, import 'package:flutter/material.dart'; là dòng đầu tiên của gần như mọi file Flutter từng được viết. Flutter 3.47 bắt đầu kết thúc điều đó. material_ui và cupertino_ui giờ là package độc lập trên pub.dev, cả hai ở 1.0, cùng do publisher đã xác minh flutter.dev phát hành. Bản trong SDK vẫn chạy — và đã lên lịch deprecate chính thức ở bản stable tháng 11.

Đây là thay đổi lớn hơn vẻ ngoài của cái diff, nên hiểu lý do trước khi chạy công cụ migrate là đáng.

Vì sao phải tách ra

Khảo sát Q2 2026 trả lời điều này rõ hơn mọi bài blog. Ở mọi mảng trọng tâm, mức hài lòng đều cao: Dart 92%, Android 91%, core framework 90%. Một con số phá vỡ quy luật — Cupertino widgets 61%, giảm 6 điểm, mảng bị chấm thấp nhất khảo sát.

Nguyên nhân cấu trúc là nhịp phát hành. Bị buộc vào SDK, Cupertino chỉ ship sửa lỗi được theo chuyến tàu stable hàng quý. Apple thì đổi thiết kế bất cứ lúc nào họ muốn. Một design system chỉ phản ứng được bốn lần mỗi năm sẽ luôn chạy sau nền tảng mà nó mô phỏng.

Khi tách ra, material_ui và cupertino_ui có thể phát hành hàng tuần. Đó là toàn bộ chiến lược: không phải refactor cho đẹp, mà là sửa một sự lệch nhịp hiện lên trực tiếp trong mức hài lòng của lập trình viên.

Lợi ích thứ hai là độc lập phiên bản. Hôm nay, nâng Flutter đồng nghĩa chấp nhận mọi thay đổi widget cùng lúc. Khi design system là một dependency bình thường, bạn ghim được nó:

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

Nâng framework để lấy một bản vá engine mà không phải nhận kèm thay đổi layout của ListTile trong cùng buổi chiều.

Thực sự đổi gì trong code

Chủ yếu là đường dẫn import:

API widget không đổi. Đây là chuyện đóng gói, không phải phá vỡ API — và đó chính là lý do nó tự động hoá được.

Chạy migrate

Thêm package, rồi để dart fix viết lại import:

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

Fix migrate_design_widgets viết lại import từ vị trí cũ trong framework sang package mới trên toàn project. Hãy đọc diff — gần như toàn bộ phải là dòng import. Thứ gì khác thì đáng nhìn lại lần hai.

Thứ duy nhất công cụ không xử lý trọn cho bạn là localizations. Nếu bạn dùng GlobalMaterialLocalizations, hãy chuyển sang bản do material_ui cung cấp thay vì bản từ flutter_localizations. Trộn hai thứ sẽ sinh lỗi “không tìm thấy localizations” khó hiểu lúc chạy chứ không phải lúc biên dịch, nên hãy grep tường minh:

grep -rn "GlobalMaterialLocalizations" lib/

Sống sót qua giai đoạn dependency pha trộn

Đây là vấn đề thực tế. Bạn migrate app trong hai mươi phút. Rồi bạn phát hiện bốn dependency vẫn import package:flutter/material.dart, và cây widget của họ với của bạn giờ đến từ hai thư viện khác nhau.

Đó là lý do MaterialUiCompatibilityBridge tồn tại. Bọc app — hoặc chỉ nhánh cây chứa widget cũ — và hai thế giới cũ mới vẫn làm việc được với nhau:

import 'package:material_ui/material_ui.dart';

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

Hãy coi bridge là giàn giáo có ngày tháo dỡ, không phải kiến trúc. Mỗi nhánh được bọc là một dependency bạn đang chờ. Giữ một danh sách.

Mốc thời gian deprecate

Hôm nay chưa có gì vỡ. Trình tự cần lên kế hoạch:

• Bây giờ (3.47): cả hai đường đều chạy. Package ở 1.0. Migrate là tuỳ chọn.
• Stable tháng 11: thư viện Material và Cupertino trong SDK bị deprecate chính thức. Hãy chờ cảnh báo analyzer trên mọi import chưa migrate.
• Về sau: API bị deprecate cuối cùng sẽ bị gỡ. Chưa có ngày công bố, và bạn không nên chờ ngày đó.

Ước lượng chi phí thành thật: một buổi chiều cho một app, lâu hơn cho một hệ sinh thái plugin bạn không kiểm soát.

Nếu bạn phát hành package

Tác giả package gánh phần nặng thật, vì lựa chọn của bạn lan tới mọi người dùng. Vài nguyên tắc:

• Đừng migrate rồi phát hành ngay một major phá vỡ nếu package của bạn chỉ chạm vài widget — bạn sẽ chia người dùng thành hai thế giới mà chẳng được gì.
• Hãy migrate sớm nếu package của bạn chính là một thư viện UI. Người dùng không hoàn tất migrate được cho tới khi bạn xong.
• Nới ràng buộc phiên bản thay vì ghim chặt, để người dùng nhận được bản vá design system mà không phải chờ bản phát hành của bạn.

Checklist migrate của bạn

1. Nâng lên Flutter 3.47 và xác nhận build sạch trước khi đổi bất cứ thứ gì.
2. Chạy flutter pub add material_ui cupertino_ui.
3. Chạy dart fix --apply --code=migrate_design_widgets và đọc diff.
4. Tìm GlobalMaterialLocalizations và đổi sang bản của material_ui.
5. Build và chạy trên ít nhất một target iOS và một Android. Chú ý riêng các hồi quy về theme và localization.
6. Xác định dependency còn dùng thư viện trong SDK. Mở issue cho họ ngay hôm nay.
7. Bọc MaterialUiCompatibilityBridge chỉ ở nơi buộc phải, và ghi lại lý do.
8. Đặt nhắc lịch tháng 10 để rà lại danh sách trước khi mốc deprecate tháng 11 tới.

Kết luận

Cuộc migrate này mang tính cơ học, và tooling làm hộ phần lớn. Phần cần phán đoán là đồ thị dependency: app của bạn thì dễ, dependency thì không, và MaterialUiCompatibilityBridge là cây cầu chứ không phải điểm đến. Hãy làm phần cơ học ngay bây giờ khi nó còn tuỳ chọn và analyzer còn im lặng — đó là việc khó chịu hơn nhiều vào tháng 11, với cảnh báo trên mọi file và một chiếc đồng hồ deprecate đang chạy.

Bài viết gốc đăng tại FlutterCook. Bản trên đó là bản được cập nhật mới nhất.