Flutter 3.44 landed at Google I/O on May 19, 2026, with a release that goes far beyond typical incremental updates. Key innovations include Hybrid Composition++ for Android, Swift Package Manager as the new iOS/macOS standard and improved Vulkan support for Impeller. By far the most consequential decision for existing projects is the switch of the dependency manager on Apple platforms — a step that is not optional, but forced by an external timeline.
What happened?
As of Flutter 3.44, Swift Package Manager (SwiftPM) replaces CocoaPods as the default dependency manager for iOS and macOS apps — without a Ruby installation, without CocoaPods setup. The background is not solely Google's strategic decision: CocoaPods is officially in maintenance mode, and its registry will become permanently read-only on December 2, 2026. New versions or pods will no longer be published after that date. At the same time, Firebase has announced that it will stop publishing new SDK versions via CocoaPods as early as October 2026 — two months before the registry freeze — to ensure that the last published versions are stable and verified.
The Flutter team writes in its official blog: “To ensure that your apps continue receiving dependency updates and to provide access to the Swift package ecosystem, Flutter is transitioning to Apple's supported dependency management solution: Swift Package Manager.” (flutter.dev/blog, April 2026)
Why is this technically and strategically significant?
For more than a decade, CocoaPods was the structural foundation for iOS dependencies in Flutter projects — and at the same time one of the most common causes of onboarding problems, CI failures and version conflicts. The Ruby-based architecture was a regular source of “works on my machine” errors in CI environments, cumbersome setup processes on new developer machines and time-consuming debugging sessions for version conflicts.
SwiftPM fundamentally solves these structural problems: Swift Package Manager is integrated directly into Xcode, maintained by Apple and has reached the functional maturity to manage complex dependency graphs. For Flutter teams, this specifically means: pod install steps are eliminated from CI scripts, since SPM resolution happens automatically during the Xcode build — provided macOS with Xcode 14+ is available, without additional tooling installations.
For most projects, the migration itself is less effort than it seems. For the majority of projects, the migration is automatic: after `flutter upgrade` to 3.44, the CLI detects the version, migrates the Xcode project to SwiftPM and downloads the Swift packages that the plugins depend on. If a project still uses plugins that do not support SwiftPM, Flutter issues a warning and falls back to CocoaPods for that specific dependency.
Concrete need for action for companies
Three factors make this topic a priority for ongoing and planned Flutter projects:
First, plugin maturity: so far, 61% of the top 100 iOS plugins have migrated. The rest must follow — and to accelerate this, packages without SwiftPM support now receive lower pub.dev scores. Teams must actively review their dependency tree and, if necessary, contact plugin maintainers or evaluate alternatives.
Second, the iOS deployment target requirement: the minimum deployment target for SPM is iOS 15.0. Firebase and many modern Swift packages require iOS 15+. Projects that still maintain older deployment targets must catch up here — a technical debt that cannot be avoided.
Third, the deadline structure: Firebase will stop publishing new SDK versions via CocoaPods as early as October 2026 — six months earlier than the registry freeze. If you have not migrated by then, you will no longer receive new Firebase updates through the previous channel. Additional native dependencies — third-party analytics SDKs, mapping libraries, payment integrations — must be evaluated separately.
Assessment and recommendation
Alongside the SPM switch, Flutter 3.44 introduces another structurally relevant innovation with Agentic Hot Reload: the MCP server automatically connects to running Dart and Flutter applications, so that coding agents such as Antigravity can trigger hot reload directly from the agent workflow — without manual intervention. This directly addresses one of the biggest friction points in AI-assisted development workflows.
The replacement of CocoaPods nevertheless deserves the highest priority, because it cannot be postponed. For teams at Portalworks, I recommend the following approach: an immediate inventory of all iOS plugins for SPM compatibility, parallel testing of the SwiftPM build on a feature branch, and completion of the migration before October 2026 — the de facto Firebase cutoff. The escape hatch via `enable-swift-package-manager: false` in pubspec.yaml can be used in the short term, but does not always work smoothly in more complex projects and remains a temporary solution. If you start now, you have enough time for a controlled migration; if you wait, you risk time pressure in the worst possible development window.
