Chuyển đến nội dung chính

Standalone material_ui and cupertino_ui: what the 1.0 split changes

Material and Cupertino used to be frozen inside the core SDK. That made design updates wait on the quarterly Flutter release train. In Flutter 3.47 both libraries reach 1.0 as standalone packages on pub.dev: material_ui and cupertino_ui.

Diagram: Standalone Material UI and Cupertino UI

You still get the SDK copies this release. The packages are opt-in. That is deliberate — the team froze contributions in April so the migration path could be boring.

Why the split matters in 2026

Three concrete outcomes:

  1. Weekly design releases. Bugfixes and new components no longer wait for flutter upgrade.
  2. Independent upgrades. An app pinned to an older SDK can still take the latest look and feel.
  3. Style-neutral core. A leaner foundation for custom design systems (and for Liquid Glass / M3 Expressive-style shocks from platform vendors).

Migrate with dart fix

flutter pub add material_ui
# if you use Cupertino:
flutter pub add cupertino_ui

dart fix --apply --code=migrate_design_widgets

The fix rewrites imports from package:flutter/material.dart / cupertino.dart to the standalone packages. If pubspec.yaml is not updated automatically (an early known bug), add the deps by hand and run dart fix --apply again.

Bridge while dependencies catch up

Not every package you depend on will migrate on day one. Wrap the app:

import 'package:material_ui/material_ui.dart';

MaterialApp(
  builder: (context, child) => MaterialUiCompatibilityBridge(child: child!),
  home: const HomeScreen(),
);

Localization unbundles with the same move — Material/Cupertino delegates now live in the packages, and GlobalMaterialLocalizations.delegates includes the Cupertino and Widgets delegates.

Pitfalls

  • Treat this as a major release if you publish packages.
  • Core SDK copies are scheduled for formal deprecation in the November stable.
  • Run widget tests after import rewrites; theme APIs are the same, but library URIs are not.

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

Nhận xét

Bài đăng phổ biến từ blog này

2026 👏 Google miễn phí một năm gói AI Plus cho sinh viên Việt Nam 🇻🇳🇻🇳🇻🇳

Chúc mừng anh em 👏 Google miễn phí một năm gói AI Plus cho sinh viên Việt Nam 🇻🇳🇻🇳🇻🇳 Đối tượng là sinh viên đại học từ 18–24 tuổi (bao gồm sinh viên mới và sinh viên từng dùng gói AI Pro 2025). Lưu ý là cần xác minh tư cách sinh viên hàng năm. Khi nhận gói, anh em có được các ưu đãi sau: 🔖 Nâng cấp bộ nhớ đám mây lên 400GB. 🔖 Nhân đôi hạn mức truy cập mô hình AI. 🔖 Mở quyền trải nghiệm tính năng tạo video bằng Gemini Omni. Lưu ý chương trình chỉ dành cho sinh viên đủ điều kiện. Hạn nhận ưu đãi: 31 tháng 12, 2026. Các bạn cần có phương thức thanh toán hợp lệ khi đăng ký. Google AI Plus sẽ tự động tính phí 132.000 ₫/tháng sau khi thời gian dùng thử kết thúc, trừ phi bạn đã huỷ trước đó. Huỷ bất cứ lúc nào. CÁC BƯỚC THỰC HIỆN CHI TIẾT 🔹Bước 1: Truy cập cổng đăng ký chương trình 🔖 Mở trình duyệt và truy cập vào trang chính thức: gemini.google/students/ 🔖 Đăng nhập vào Tài khoản Google cá nhân của bạn. 🔖 Nhấn vào nút "Claim your student plan at no cost" (hoặc Nhận gó...

5 concepts every Flutter dev should know

  Phụ lục: State management architecture Testing IDE Shortcuts Platform channel Maintaining a project Tôi đã làm việc với Flagship trong một thời gian dài, và đây là những điều mà tôi phát hiện ra là điều cần phải có đối với bất kỳ nhà phát triển Flagship nào, về tổng thể nó sẽ khiến bạn trở thành một nhà phát triển Flagship giỏi trong thời gian dài. 1. State management architecture Đây là một trong những chủ đề quan trọng nhất trong cộng đồng thiết bị rung, nó khá quan trọng nếu bạn muốn duy trì một dự án rung kích thước trung bình hoặc lớn. Nó sẽ giúp tạo một dự án suôn sẻ và thêm các tính năng mới một cách hoàn hảo.  2. Testing Đây là một chủ đề duy nhất mà tôi không hiểu tại sao nó lại quan trọng trước đó trong sự nghiệp của tôi, nhưng khi tôi tiến lên trong sự nghiệp của mình và có kinh nghiệm với nhiều dự án và vấn đề xảy ra trong môi trường sản xuất. Tôi đã nhận ra một cách khó khăn, tại sao điều này lại quan trọng như vậy. Nếu bạn vẫn muốn có thêm lý do để cân nhắc thử...

Lovable rời Next.js sau 6 tháng: những con số và phần bạn thật sự dùng lại được

Đội Lovable vừa công bố nhật ký cuộc di trú của họ: rời Next.js trên Vercel để sang TanStack Start chạy trên Cloudflare workerd . Sáu tháng cho phần code, thêm hai tháng cho phần rollout, trên một sản phẩm đang phục vụ hàng chục triệu lượt truy cập. Bài gốc đáng đọc nguyên văn — How we migrated lovable.dev away from Next.js . Bài này không dịch lại nó. Tôi tóm những con số đã được công bố, rồi tách ra hai thứ mà một bài “chúng tôi đã đổi framework” thường trộn lẫn: phần chỉ đúng ở quy mô của họ , và phần một đội năm người cũng dùng lại được ngay tuần sau . Vì sao họ đổi, và vì sao lý do đó không phải là “Next.js tệ” Ba động cơ, không cái nào là chê framework: Ăn đồ mình nấu. Lovable sinh ra ứng dụng cho người dùng, và những ứng dụng đó chạy trên hạ tầng worker của chính họ. Sản phẩm chính lại chạy trên một stack khác. Mỗi lần nền tảng hở chỗ nào, đội làm sản phẩm không phải người đầu tiên đau. Quy mô một-ứng-dụng. Trang chính là một ứng dụng lớn duy nhất chịu tải rất cao — khác...