Flutter 3.47の新機能

What’s new in Flutter 3.47 Modular by design: Standalone UI Packages and Impeller on Desktop Emma Twersky Aug 12, 2026 · 12 min read rss_feed share content_copyCopy link Share on X Share on Bluesky Share on LinkedIn What's new in Flutter 3.47 Flutter 3.47 is here, and with it, we’ve got some exciting new updates. Today, we welcome the 1.0 release of the standalone material_ui and cupertino_ui packages. This is a major milestone that decouples design systems from the core SDK. We’re also boosting performance and tooling across the board. This release brings Impeller to desktop by default, prepares our pipelines for iOS, macOS, and Xcode 27, and graduates Flutter Widget Previews to stable. So, run flutter upgrade in your terminal to get started, or read on to learn more about the major changes in this release. Choose your own UI adventure The first step toward a decoupled Flutter is here: Material and Cupertino are now available as standalone packages! One of Flutter’s greatest strengths is its ability to render pixel-perfect Material and Cupertino widgets. However, because these design libraries were historically bundled directly inside the core SDK, it slowed down their development and made it harder to contribute or keep them up to date. While the core SDK still includes these libraries for this release, you can now opt-in to the standalone material_ui and cupertino_ui packages, which have officially reached version 1.0 on pub.dev. Decoupling design roadmaps (Opt-in) By opting into the decoupled design systems, you gain control over your design roadmap. Because material_ui and cupertino_ui now live on pub.dev, they can ship bug fixes and new components on their own weekly schedules, independent of the quarterly Flutter SDK releases. Decoupling the design systems gives us the following benefits: You can use the latest Cupertino and Material widget styles without being forced to upgrade your entire Flutter SDK version. We can land contributions and updates faster and more frequently. We lay the groundwork for a style-neutral Flutter core widget catalog, making it easier to build custom design systems in the future. How to migrate To migrate your project to the new standalone packages, run the following command: bash dart fix --apply --code=migrate_design_widgets content_copy This tool automatically updates your imports from package:flutter/material.dart and package:flutter/cupertino.dart to the new standalone packages. Note: If the migration tool encounters issues updating your pubspec.yaml (a known early bug), you can resolve it by manually running flutter pub add material_ui (and cupertino_ui if you use it), then running dart fix --apply once more. The original design libraries inside the core SDK are scheduled for formal deprecation in the upcoming Fall stable release in November. If you are migrating a package in the ecosystem, treat this move to the standalone packages as a major release. Bridging the migration gap To facilitate bridging the gap as the ecosystem migrates to the new standalone design libraries, material_ui and cupertino_ui ship with migration utilities. The MaterialUiCompatibilityBridge allows your application to migrate to the standalone packages immediately, even if some of your package dependencies are still using legacy core SDK imports. For example, you can wrap your app in the compatibility bridge: dart import 'package:material_ui/material_ui.dart'; ​ void main() { runApp(const MyApp()); } ​ class MyApp extends StatelessWidget { const MyApp({super.key}); ​ @override Widget build(BuildContext context) { return MaterialApp( theme: ThemeData( colorScheme: ColorScheme.fromSeed(seedColor: const Color(0xFF6750A4)), ), builder: (BuildContext context, Widget? child) { return MaterialUiCompatibilityBridge(child: child!); }, home: const HomeScreen(), ); } } content_copy Decoupled localizations As part of this transition, flutter_localizations has also been unbundled. Localization delegates and translated strings for Material and Cupertino widgets now reside inside package:material_ui and package:cupertino_ui respectively. Before: dart import 'package:flutter_localizations/flutter_localizations.dart'; import 'package:flutter/material.dart'; ​ // ... localizationsDelegates: const <LocalizationsDelegate<dynamic>>[ GlobalCupertinoLocalizations.delegate, GlobalMaterialLocalizations.delegate, GlobalWidgetsLocalizations.delegate, ], content_copy After: dart import 'package:material_ui/material_ui.dart'; ​ // ... localizationsDelegates: GlobalMaterialLocalizations.delegates, content_copy Setting localizationsDelegates to GlobalMaterialLocalizations.delegates now includes the Cupertino and Widgets delegates as well, simplifying your setup. Decoupling localization structure Open for contribution By freezing contributions to the Material and Cupertino libraries back in April, we’ve been able to ensure a smooth migration. The libraries waiting for you in material_ui and cupertino_ui are the same libraries you are already using. Now that we are ready to lift the freeze, look forward to more fixes and features rolling out on a regular basis in the new packages, with releases currently planned to land weekly. We are also excited to officially open these packages for community contributions. Prepping for the next wave of Apple updates With Xcode 27, iOS 27, and macOS 27 arriving this fall, we have focused heavily on making sure Flutter is ready for the upcoming updates. To ensure your users don't experience day-one surprises, we recommend testing your apps against the Apple betas now. Additionally, to support Xcode 27, the minimum supported OS versions have been bumped: PlatformPrevious minimumNew minimum (Flutter 3.47+) iOS1315macOS10.1512 UIScene lifecycle mandate The iOS 27 SDK now mandates the UIScene lifecycle for all UIKit-based apps. Apps built with Xcode 27 that do not adopt UIScene will fail to launch on startup. For most apps, the Flutter CLI handles this migration automatically during the build. However, manual migration is required if you have custom native code in your AppDelegate or use plugins that still rely on the legacy application lifecycle. In those cases, you must migrate manually by following the UIScene/Delegate Adoption Guide. Phasing out Intel Macs In alignment with Apple's transition to Apple Silicon, Flutter is winding down support for Intel-based Macs. We have disabled automated test runs on Intel hardware, and the Flutter CLI now prints warnings when building on Intel hosts or targeting dual architectures. These warnings will become errors in a future release. You can opt in to building ARM64-only macOS apps immediately by running flutter config --enable-macos-arm64-only. Swift Package Manager progress The community has made incredible progress transitioning to Swift Package Manager, with 92 of the top 100 iOS plugins now migrated. If you previously turned Swift Package Manager off, you can try it again by running flutter config --enable-swift-package-manager. Because CocoaPods is now in maintenance mode, plugins that do not migrate to SwiftPM will eventually stop working. Unmigrated plugins also receive lower pub.dev scores. If you maintain a plugin, consult the Migration Guide and read our previous blog post for more details. This release also features optimized build times, thanks to community contributor @lukemmtt, who improved build pipelines by filtering out unnecessary SwiftPM package schemes early in the build process. Setting course for Wasm by default We are actively working toward enabling WebAssembly (Wasm) by default for Flutter web applications, bringing native-like performance to the browser. If you haven’t tested your web apps with Wasm yet, you can opt-in today by passing the --wasm flag to your release build command: bash flutter build web --release --wasm content_copy As you prepare for this transition, keep in mind that Wasm requires migrating your codebase to the new JS interop package (package:web)