Flutter 3.44 in production: the upgrade plan for teams shipping real apps

Summary. Flutter 3.44 reached stable in May 2026 alongside Dart 3.12, and the current patch is 3.44.6, released on July 8, 2026. Three changes decide how expensive your upgrade is. Swift Package Manager replaced CocoaPods as the default dependency manager for iOS and macOS. Contributions to the Material and Cupertino libraries were frozen on April 7, 2026, one release cycle ahead of their move to standalone packages. Android gained Android Gradle Plugin 9 support with built-in Kotlin, and IconData is now final. The CocoaPods registry becomes read-only on December 2, 2026, which makes the iOS half of this a deadline rather than a preference. For a mid-size app with 25 to 40 plugins, we budget two to four senior engineer-days, roughly $600 to $1,600 (about ₹50,000 to ₹1,40,000) at July 2026 rates. The upgrade itself is rarely the hard part. The plugins you do not control are.

Most of the coverage of this release has focused on what is new. That is the wrong question for a team with an app in the stores. The useful question is narrower: what breaks, what has a deadline attached, and what can safely wait until 3.47. This guide answers those three, in the order we run them on client projects.

What actually changed, and what it costs you

Change in 3.44	Who it affects	Action this quarter
SwiftPM is the default dependency manager	Every iOS and macOS app	Upgrade, let the CLI migrate, audit plugins that lack SwiftPM support
Material and Cupertino contributions frozen (April 7, 2026)	Every app using material.dart	Nothing to import yet. Stop forking these libraries and remove deep imports
AGP 9 support and built-in Kotlin	Android apps and plugin authors	Drop the manual Kotlin Gradle plugin block once you move to AGP 9
IconData marked final and @mustBeConst	Packages that extend or implement IconData	Replace subclassing with composition before you upgrade
Hybrid Composition++ (HCPP), opt-in	Android apps embedding native views	Test behind the flag on API 34+ devices. Do not ship it by default
onReorder deprecated in ReorderableListView	Apps with reorderable lists	Move to onReorderItem and delete the index-adjustment workaround
findChildIndexCallback deprecated	ListView.separated, SliverList.separated users	Rename to findItemIndexCallback

Two rows on that table have real deadlines. The rest are housekeeping you can schedule.

Swift Package Manager is now the default on iOS and macOS

This is the change that will consume your week. As of 3.44, Flutter uses Swift Package Manager to manage iOS and macOS native dependencies by default. CocoaPods continues in maintenance mode, but the registry becomes read-only on December 2, 2026. After that date no new pods or versions land in the trunk. Existing builds keep working. Nothing new arrives.

The migration is mostly automatic. When you build or run an iOS or macOS app on 3.44, the Flutter CLI updates the Xcode project to add SwiftPM integration. You lose the Podfile, the pod install step, and the Ruby toolchain that CI has been quietly maintaining for years.

The failure mode is plugins. Not every plugin has published SwiftPM support, and Flutter falls back to CocoaPods for the ones that have not. That fallback works, so the upgrade will look clean, and you will not discover the gap until the December deadline gets closer. Audit it deliberately instead:

flutter upgrade
flutter clean
cd ios && rm -rf Pods Podfile.lock && cd ..
flutter build ios --config-only

Read the build output. Flutter warns about dependencies without SwiftPM support and names them. File an issue against each plugin, and record the list somewhere your team will see it again in October.

If SwiftPM breaks a build you need to ship today, turn it off for the project rather than for yourself:

# pubspec.yaml
flutter:
  config:
    enable-swift-package-manager: false

That setting applies to everyone working on the project, which is the behaviour you want in a team. The per-user escape hatch is flutter config --no-enable-swift-package-manager, and it will bite you when CI does not share the setting. The Flutter documentation is blunt about the whole idea: "In general, don't do this. Remember that the CocoaPods registry becomes read-only on December 2, 2026 and disabling SwiftPM won't be allowed in the future."

If you previously disabled SwiftPM on an earlier version, re-enable it with flutter config --enable-swift-package-manager before you start, or the migration will silently skip your project.

One more detail worth knowing before it costs you an afternoon: SwiftPM and CocoaPods can conflict when a plugin ships both. Flutter 3.44 added a guided error message for that case, so read the error rather than deleting Pods/ in a loop.

The Material and Cupertino freeze, and what it does not mean yet

On April 7, 2026, the Flutter team froze contributions to the Material and Cupertino libraries in flutter/flutter. The tracking issue states the scope plainly: contributions "will be frozen as part of decoupling beginning at the next stable release cutoff on April 7th." The libraries are moving out of the SDK into standalone material_ui and cupertino_ui packages with independent versioning, closing out a long-standing request in the decoupling tracking issue.

The reason for freezing early is mechanical. Justin McCandless, a software engineer on the Flutter team at Google, explained the sequencing in the official announcement: "We can achieve this by freezing the code one stable release cycle ahead and copying that frozen code to the new packages." Freeze first, copy the frozen code, then release the packages. That keeps the eventual migration close to a find-and-replace instead of a rewrite.

Here is the part several write-ups have wrong. As of July 2026, material_ui on pub.dev is a reserved placeholder described as "coming soon", not a shipping 1.0.0 package. Flutter 3.44 does not deprecate package:flutter/material.dart, and it does not emit a warning when you import it. Your existing imports are correct, supported, and should stay exactly as they are. If a blog post tells you to swap your imports to package:material_ui/material_ui.dart today, it is describing a future you cannot install yet.

What you should do now is cheaper than a migration and pays off either way:

• Stop forking Material or Cupertino. A fork you carry across the package split is the one thing that turns a mechanical migration into a project.
• Remove incidental material.dart imports from files that only need widgets.dart. Material exports the widgets library, so it is easy to depend on Material by accident. Those accidental imports are what make the split feel expensive later.
• Keep a list of the Material widgets you have subclassed rather than composed. Subclasses are where breaking changes land.

We cover the package split and the migration mechanics in more depth in our guide to the Material UI and Cupertino UI package migration. For this release, the correct action is to do nothing and stop making it worse.

Android: AGP 9, built-in Kotlin, and one real breaking change

Flutter 3.44 adds support for Android Gradle Plugin 9 and moves Android projects toward built-in Kotlin configuration. Before AGP 9, app and plugin authors had to add the Kotlin Gradle plugin to their build files manually so the build system could compile Kotlin at all. As of AGP 9.0, the Android build system handles Kotlin natively, and that boilerplate goes away.

The breaking change that will actually fail your build is quieter. IconData is now marked final and @mustBeConst. Any package that extends or implements IconData stops compiling. Icon-font packages are the usual offender, because subclassing IconData was a common way to attach a custom font family. The fix is composition or a constant factory, not a subclass. Check your dependency tree before you upgrade rather than after:

grep -rn "extends IconData\|implements IconData" ~/.pub-cache/hosted/pub.dev/ | head

The @mustBeConst annotation is the second half of that change, and it is deliberate. IconData fields are marked as tree-shaking entrypoints, and const construction is what lets the toolchain drop unused icons from your font. Code that builds IconData at runtime from a variable will now be rejected at compile time, which is a real constraint if you drive icons from a CMS or a remote config. Map the remote value to a const lookup table instead.

Hybrid Composition++, and why we are not shipping it yet

HCPP is the most interesting thing in 3.44 and the one we are slowest to recommend. It is opt-in, and it should stay that way in your app for at least one more release.

The mechanism is genuine engineering rather than a marketing line. Instead of round-tripping native views through offscreen buffers, HCPP delegates layer compositing to the Android OS through Vulkan, using hardware buffer swapchains and SurfaceControl transactions to synchronise the Flutter UI with native Android views. The Flutter team's own description of the result is specific: high-performance scrolling, accurate touch, and reliable SurfaceView support. If you have ever embedded a map or a video player and watched the scroll fall apart or a tap land 40 pixels off, that is the class of bug this targets.

The constraints matter more than the benefits right now:

• HCPP requires Android API 34 or later, because it depends on native transaction synchronisation.
• The device must be able to render with Vulkan.
• It is enabled with the --enable-hcpp flag or a meta-data entry in AndroidManifest.xml, not by default.

flutter run --enable-hcpp

Read those requirements against your actual install base, not against the newest device on your desk. An Android app in India that still supports API 26 will run the old path for most of its users, which means HCPP gives you a second rendering path to test rather than a faster app. Enable it in a build flavour, measure it on the screens where you embed native views, and keep it behind the flag until your API 34+ share justifies owning both paths.

The honest read: HCPP is the right destination and a poor Tuesday afternoon decision. It is also the strongest argument in this release for keeping your minSdkVersion conversation on the roadmap, since the payoff arrives when your floor reaches API 34.

The deprecations to clear now, while they are still warnings

Deprecated API	Replacement	Where it bites
onReorder in ReorderableListView	onReorderItem	The new callback reports a newIndex that already accounts for the removed item, so delete your manual if (newIndex > oldIndex) newIndex-- fix
findChildIndexCallback	findItemIndexCallback	ListView.separated and SliverList.separated; a rename, but it is silent until you read the analyzer output
builder and pageBuilder in showCupertinoSheet and CupertinoSheetRoute	scrollableBuilder	Scrollable content inside a sheet; the new builder integrates with the sheet's drag animation
--web-hot-reload flag	No flag needed	CI scripts and IDE run configurations, which is where stale flags hide
plugin_ffi template	plugin template with FFI support	New plugin scaffolding only; existing plugins are unaffected

The onReorder change is the one worth doing by hand rather than with a rename. Almost every codebase has the index-adjustment workaround written into the callback, and onReorderItem makes it wrong rather than unnecessary. Delete the workaround when you migrate the callback, or your list will reorder to the wrong slot in exactly the cases your tests do not cover.

The RawMenuAnchor callback ordering also changed in this release. If you built a custom menu on top of it, your callbacks now fire in a different order. That is a small blast radius and a genuinely confusing debugging session if you do not know it happened.

The staged upgrade plan we actually run

Six steps, in this order. The order is the point: every step after the first is cheaper once the one before it is clean.

1. Upgrade the floor, not the app. Move to 3.44.6 rather than 3.44.0. The 3.44 series has taken six patches since May, and 3.44.6 shipped on July 8, 2026 with no Dart version change, so the cherry-picks are stability fixes rather than new surface area.

flutter upgrade
flutter --version   # expect 3.44.6

2. Audit before you build. Grep for IconData subclasses and onReorder usage, and list plugins without SwiftPM support. This is 30 minutes that decides whether step 4 takes an hour or two days.

3. Take the analyzer seriously for one afternoon. Run dart analyze and fix every deprecation warning in the table above while they are still warnings. Deprecated APIs get removed, and the cost of clearing them never goes down.

4. Let the iOS migration happen, then verify it. Build with --config-only, read the plugin warnings, and commit the Xcode project changes deliberately in their own commit. A reviewer can understand a SwiftPM migration commit. Nobody can review it mixed into a feature branch.

5. Test the platform seams, not the widgets. Your widget tests will pass. The risk in this release sits at the native boundary: plugins, platform views, icon fonts, and reorderable lists. Test those on real devices.

6. Ship the SDK bump on its own. No feature work in the upgrade release. When something regresses in production two days later, you want a one-line revert rather than an argument about which change caused it.

Workstream	Typical effort (mid-size app)	Risk if deferred to 2027
SwiftPM migration and plugin audit	1 to 2 engineer-days	High. The CocoaPods registry is read-only from December 2, 2026, and unmigrated plugins stop receiving fixes
Deprecation cleanup (onReorder, findChildIndexCallback, Cupertino sheets)	0.5 to 1 engineer-day	Medium. Warnings become removals in a later release, and the work grows with the codebase
IconData and icon-font fixes	0.5 to 1 engineer-day	High. This is a hard compile failure, not a warning
Material and Cupertino hygiene (de-fork, fix stray imports)	1 to 2 engineer-days	Medium. The package split is coming and forks are what make it expensive
HCPP evaluation	0.5 engineer-day, then park it	Low. It is opt-in and your API 34+ share decides the timing

Our estimate for the whole exercise is two to four senior engineer-days for an app with 25 to 40 plugins, and most of the variance is in that first row. Teams with a heavy native surface (maps, video, payments SDKs, custom icon fonts) should plan for the top of the range. The real cost is usually the plugins you do not control, not the code you wrote.

India-specific considerations

Two things change the calculation for teams shipping from or into India.

The first is device mix. HCPP requires Android API 34 or later and a Vulkan-capable device. If your app supports the mid-range and older Android install base that most consumer products in India still serve, HCPP will not reach a meaningful share of your users this year. Treat it as a 2027 line item and spend the time on the SwiftPM audit instead, which has an actual deadline.

The second is process, not code. If your app handles personal data, an SDK upgrade is a good moment to re-check what your plugins send off-device, because the Digital Personal Data Protection Act, 2023 turns third-party SDK behaviour into your obligation rather than the vendor's. A plugin audit for SwiftPM support and a plugin audit for data flows read the same dependency list. Doing them in one pass is close to free, and it is the only time this quarter your team will willingly look at all 40 plugins. We design applications aligned with DPDP requirements, and the plugin inventory is where that work starts.

For teams weighing the framework decision itself rather than the upgrade, our React Native versus Flutter hiring decision framework covers the staffing side, and the Dart 3.12 language changes that ship with this release cut real boilerplate once you are on 3.44. The Impeller rendering changes are worth reading alongside the HCPP section, since both decide what your Android frame budget looks like.

What we would not do this quarter

Three things in this release look urgent and are not.

Do not migrate imports to material_ui. The package is not released. There is nothing to migrate to, and the deprecation warning that several posts describe does not exist in 3.44.

Do not enable HCPP by default. It is opt-in for a reason, it needs API 34 and Vulkan, and shipping it broadly means owning two rendering paths through the next release cycle.

Do not disable SwiftPM to make the upgrade quiet. It works, and it will keep working right up to December 2, 2026, at which point it becomes someone's emergency. Take the two days now.

FAQ

Is Flutter 3.44 safe to use in production?

Yes. Flutter 3.44 reached stable in May 2026 and has since taken six patch releases, with 3.44.6 shipping on July 8, 2026 and requiring no Dart version change. Move to the latest patch rather than 3.44.0, test the native boundary on real devices, and ship the SDK bump without feature work attached.

Do I need to change my Material imports in Flutter 3.44?

No. Contributions to Material and Cupertino were frozen on April 7, 2026, but the libraries still ship inside the SDK. The material_ui package on pub.dev is a placeholder marked "coming soon", and 3.44 emits no deprecation warning on package:flutter/material.dart. Keep your imports exactly as they are.

What happens if I ignore the SwiftPM migration?

Your builds keep working, because Flutter falls back to CocoaPods for plugins that lack SwiftPM support. The problem arrives on December 2, 2026, when the CocoaPods registry becomes read-only and no new pods or versions land in the trunk. Existing builds survive. New fixes do not reach you.

How do I turn off Swift Package Manager if it breaks my build?

Set enable-swift-package-manager to false under the config subsection of the flutter section in pubspec.yaml. That applies to every contributor on the project, which is what you want. The per-user command flutter config --no-enable-swift-package-manager will not be shared with your CI environment.

Why does my icon font package fail to compile on 3.44?

Flutter 3.44 marked IconData as final and @mustBeConst, so packages that extend or implement it no longer compile. The fields are tree-shaking entrypoints, and const construction is what lets unused icons be dropped from the font. Replace subclassing with composition, and map any runtime icon values to a const lookup table.

Should I enable Hybrid Composition++ in my Android app?

Not by default yet. HCPP delegates layer compositing to the Android OS through Vulkan and improves scrolling and touch accuracy around embedded native views, but it requires Android API 34 or later and a Vulkan-capable device. Test it behind the --enable-hcpp flag on the screens that embed native views.

What is the actual breaking change in ReorderableListView?

The onReorder callback is deprecated in favour of onReorderItem, which reports a newIndex that already accounts for the item being removed before reinsertion. If you migrate the callback but keep the usual manual index adjustment, your list will reorder to the wrong position. Delete the workaround when you change the callback.

How long does a Flutter 3.44 upgrade take?

We budget two to four senior engineer-days for a mid-size app carrying 25 to 40 plugins, at roughly $600 to $1,600 as of July 2026. Most of the variance sits in the SwiftPM plugin audit. Apps with a heavy native surface such as maps, video, or payments SDKs should plan for the upper end.

How eCorpIT can help

eCorpIT runs Flutter upgrades as a scoped piece of work rather than a background task that never finishes: a dependency and plugin audit, the SwiftPM migration with the plugin gaps documented, deprecation cleanup, and device testing across the native boundary where these releases actually break. Our senior engineering teams have been shipping Flutter applications since 2021, and we plan upgrades around your release calendar instead of Google's. If you want the 3.44 upgrade costed against your own plugin list before the December 2, 2026 CocoaPods deadline, talk to our team.

References

1. Flutter 3.44.0 release notes - Flutter documentation
2. Swift Package Manager for app developers - Flutter documentation
3. Swift Package Manager for plugin authors - Flutter documentation
4. CocoaPods Specs repository becomes read-only - CocoaPods blog
5. Saying goodbye to CocoaPods: Swift Package Manager is soon the default in Flutter - Jenn Magder, Flutter blog
6. Flutter's Material and Cupertino code freeze - Justin McCandless, Flutter blog
7. Freeze Material and Cupertino during decoupling (issue 184093) - flutter/flutter
8. Move the material and cupertino packages outside of Flutter (issue 101479) - flutter/flutter
9. Flutter Release Version 3.44.6 (issue 189142) - flutter/flutter
10. What's new in Flutter 3.44 - Flutter blog
11. Breaking changes and migration guides - Flutter documentation
12. Hosting native Android views with platform views - Flutter documentation
13. material_ui package - pub.dev
14. Announcing Dart 3.12 - Dart blog
15. Mark IconData final and mustBeConst (PR 181345) - flutter/flutter
16. Deprecate onReorder callback (PR 178242) - flutter/flutter
17. Add a CLI flag for toggling HCPP use (PR 182516) - flutter/flutter
18. Digital Personal Data Protection Act, 2023 - Ministry of Electronics and Information Technology, Government of India
19. Digital Personal Data Protection Act, 2023 (No. 22 of 2023), official text - India Code

Last updated: July 16, 2026.