With Flutter 3.44, released as part of Google I/O at the end of May 2026, the Flutter team has addressed two long-standing structural problems at once: the tight binding of the design libraries to the SDK release cycle and the performance compromise in embedding native Android views that developers have complained about for years. Neither decision is a cosmetic improvement; both set the course for the next years of the Flutter platform architecture.
The most significant change is the decoupling of the Material and Cupertino libraries from the core framework. The libraries were frozen with this release: Flutter 3.44 contains the final state before Material and Cupertino appear as standalone packages `material_ui` and `cupertino_ui` on pub.dev. As of the next stable release, the previous versions in the framework itself will be deprecated. What sounds like a restructuring measure at first glance is in reality the answer to a fundamental architectural problem. As Flutter grew from a mobile UI toolkit into a multi-platform environment for web, Windows, macOS, Linux, and embedded systems, the tight coupling became a brake: core widgets are linked to specific design systems, which makes fully custom UIs more difficult and prevents the independent further development of these design libraries.
The practical effect for project teams is direct: until now, every Material 3 adjustment and every Cupertino bug fix waited for the next quarterly cut. With the standalone packages, the design team has its own release rhythm. A `material_ui: ^1.0.0` in the `pubspec.yaml` delivers Material updates as soon as they land on pub.dev, decoupled from the Dart SDK version of your own CI pipeline. For teams that run projects on a frozen Flutter version over several quarters — which is common in enterprise environments — this means: design system changes become manageable independently of framework upgrades. Another effect concerns binary size: after the complete transition, apps that use only Cupertino no longer drag Material's theming, typography, and icon set into the bundle.
Justin McCandless precisely describes the starting point of the process: “We've been hard at work preparing to decouple Material and Cupertino from the Framework, and now our first major milestone has arrived! As of April 7th, all contributions to the Material and Cupertino libraries in flutter/flutter are frozen.” (blog.flutter.dev, April 2026) The migration is deliberately designed to be low-friction: the existing import `package:flutter/material.dart` still works in 3.44 but generates a deprecation warning. The actual switch to `package:material_ui/material_ui.dart` is mechanical and can be done with the help of dart fix.
In parallel, Flutter 3.44 uses Hybrid Composition++ (HCPP) to solve a technical problem that has regularly forced compromises in production projects with maps, WebViews, or video players. The previous model offered two inadequate options: Virtual Display with input latency and SurfaceView limitations, or classic Hybrid Composition with performance losses due to additional GPU compositing passes. HCPP delegates layer compositing directly to the Android operating system, using Vulkan's low-level access via hardware buffer swapchains and SurfaceControl transactions to synchronize the Flutter UI and native Android views. The result: high-performance scrolling and precise touch input as well as reliable SurfaceView support that older modes could not deliver. Touch events are now routed correctly to both Flutter widgets and embedded native views — a long-standing source of hit-testing bugs.
HCPP is opt-in in 3.44. It is activated via the `--enable-hcpp` flag or via a manifest entry. That is the right decision: teams with intensive use of platform views — for example in fintech apps with embedded camera flows or navigation apps with Google Maps integration — should test HCPP on real devices now, before the mode becomes the default in an upcoming release.
For Portalworks projects, this results in a concrete need for action on two levels. First: existing codebases that import `package:flutter/material.dart` or `package:flutter/cupertino.dart` will produce deprecation warnings as of the next stable release. The previous architecture forced unexpected UI breaking changes during SDK upgrades due to Material 2 to Material 3 shifts and tied design improvements to the quarterly release calendar. An early migration to `material_ui` and `cupertino_ui` prevents this debt from accumulating. Second: projects with native Android embeds should evaluate HCPP in a dedicated test phase. Production teams should check the feature on real devices, especially if the app relies heavily on WebView, Maps, Ads, or Video.
Flutter 3.44 balances significant architectural shifts with a clear focus on quality: the strategic decoupling of the Material and Cupertino libraries runs in parallel with extensive web rendering improvements and deeper platform integration. This is not a short-term feature drop, but the completion of several years of restructuring work — and the beginning of a more flexible, more modular Flutter architecture that is considerably better suited to long-lived enterprise projects than the previous monolithic SDK model.
