Flutter 3.47 Released: Material and Cupertino Become Standalone Packages, iOS 15 Minimum
The Flutter team published its Flutter 3.47 release announcement on August 12, 2026. Most quarterly Flutter releases are a list of improvements that an app owner can absorb during routine maintenance. This one is different, because it starts a structural change to how every Flutter app gets its buttons, dialogs and navigation bars, and it raises the minimum iOS version that Flutter apps can support.
If your product was built through Flutter app development, nothing breaks the day you read this. Apps already in the stores keep running. The changes apply when your team upgrades the Flutter SDK, and one of them comes with a follow-up milestone that Flutter has scheduled for November.
Below is what shipped as stable, what is still experimental, what has been announced for later, and how to plan around it.
What shipped in Flutter 3.47
According to the announcement, the stable parts of the release are:
- Version 1.0 of two new standalone packages, material_ui and cupertino_ui, which hold Flutter's Material (Android-style) and Cupertino (iOS-style) design components.
- Higher minimum operating system versions for Apple platforms, and groundwork for Xcode 27 and the iOS 27 SDK.
- Impeller, Flutter's rendering engine, as the default on macOS, Windows and Linux.
- Widget Previews, a tool that lets developers render individual interface components without launching the whole app, now marked stable.
The post labels other items as experimental, including WebAssembly builds for the web and popup windows on Windows and Linux. Those are worth watching, but should not be part of a delivery commitment yet.
Material and Cupertino move out of the core SDK
Until now, the design libraries were part of Flutter itself. Nearly every Flutter app begins by importing the Material library from the framework. In 3.47, the team announced the 1.0 release of the standalone material_ui and cupertino_ui packages and said that the core SDK still includes the original libraries for this release, so moving to the new packages is opt-in for now.
The reason given is release speed. Because the packages are published separately from the SDK, the announcement says updates are currently planned to land weekly rather than waiting for the quarterly Flutter release. Flutter's migration guide adds that contributions to the in-framework libraries have been frozen since Flutter 3.44, which means fixes and new design components will arrive in the standalone packages.
How the migration works
The migration guide describes an automated route: a single dart fix command that rewrites the imports and adds the packages as dependencies. It also documents a manual route and a change to how localization is configured. For apps whose third-party packages have not yet moved, Flutter provides a compatibility bridge component so that migrated app code and unmigrated dependencies can work together during the transition.
The November milestone
This part is announced, not yet in effect. The 3.47 post states that the original design libraries inside the core SDK are scheduled for formal deprecation in the next stable release, which it places in November. Deprecation in software normally means warnings and a notice period, not immediate removal, and Flutter has not published a removal date in the pages we read. The announcement also advises authors of ecosystem packages to treat the move as a major release, so expect a wave of major version updates across the plugins your app depends on.
iOS and macOS: higher minimums and Xcode 27 preparation
The announcement says that, to support Xcode 27, Flutter's minimum supported versions rise from iOS 13 to iOS 15 and from macOS 10.15 to macOS 12. Once your app is built with Flutter 3.47 or later, users on older versions will no longer receive your updates. They keep whichever version they already have installed.
The second iOS item concerns something called the UIScene lifecycle, which is the way a modern iOS app tells the system about its windows. Flutter reports that the iOS 27 SDK makes this mandatory and that apps built with Xcode 27 that have not adopted it will fail to launch. The post says the Flutter command line tool handles the migration automatically during the build for most apps, but that manual work is needed if the project has custom native code in its AppDelegate or uses plugins that still rely on the older lifecycle.
Two related notes from the same post: 92 of the top 100 iOS plugins have now migrated to Swift Package Manager, and because CocoaPods is in maintenance mode, plugins that never migrate will eventually stop working. Flutter is also winding down support for Intel-based Macs as build machines, with warnings now and errors planned for a future release.
Impeller becomes the default renderer on desktop
Impeller is already the renderer for Flutter on mobile. With 3.47 it becomes the default on macOS, Windows and Linux as well. The stated benefit is removing the brief stutter that occurs when shaders are compiled the first time an animation runs. The post explains how to opt out temporarily, and says those fallback options will be removed in a future release, so teams that hit a rendering problem are asked to report it rather than stay on the old renderer.
This matters mainly to businesses shipping Flutter desktop software, such as internal tools, kiosks or point-of-sale screens. For mobile-only products it changes nothing.
Android build toolchain
The release post lists the Android toolchain versions that 3.47 is aligned with: Java 17 as the minimum, Kotlin Gradle Plugin 2.4.0, Android Gradle Plugin 9.1.0 and Gradle 9.3.1, with new projects defaulting to API level 36 for compile and target SDK and API level 24 as the minimum. For an app owner, the relevant point is that an older project may need its Android build files updated as part of the upgrade, and that build servers must run a compatible Java version.
What this means for your business
What follows is our interpretation, offered as guidance. Flutter 3.47 is a maintenance release in terms of risk to live apps, and a planning release in terms of workload. The design library move is mechanical for a small app and more involved for a large one with many dependencies or a customized design system, because every dependency needs to be compatible on the other side.
The minimum iOS version is a product decision as much as a technical one. Before upgrading, check your own analytics for how many active users are on iOS 13 or 14. For most consumer apps the share will be small, but your data is the only reliable answer, and some enterprise device fleets are kept on older versions deliberately.
The UIScene change is the item with a hard edge. If your project includes custom native iOS code, for example for push notifications, deep links or a payment SDK, confirm that it has been reviewed before anyone builds a release with Xcode 27.
What to do next
- Ask your development team which Flutter version the app is on today and when it was last upgraded.
- Check your analytics for users on iOS 13, iOS 14 and macOS versions below 12, and decide whether dropping them is acceptable.
- Have the team run the upgrade to 3.47 on a branch, including the automated design library migration, and list any third-party packages that block it.
- Review any custom AppDelegate code and iOS plugins for UIScene compatibility.
- Schedule the design library migration before, or shortly after, the November release so that deprecation warnings do not pile up alongside other work.
Conclusion
Flutter 3.47, announced on August 12, 2026, makes the standalone Material and Cupertino packages available at version 1.0, raises the minimum supported iOS and macOS versions, prepares apps for Xcode 27, and switches desktop apps to Impeller by default. The deprecation of the built-in design libraries is announced for November, which gives teams a clear window to migrate on their own schedule.
If you want help assessing what the upgrade involves for your app, contact us. Entrant Technologies builds websites, web applications, mobile apps and custom software, and a short review of your dependencies is usually enough to size the work.