Add-to-App Gets More Flexible in Flutter 3.44
Flutter 3.44 makes SwiftPM the iOS/macOS default and adds flutter build add-to-app packaging as a Swift Package. What it changes.
Published on • October 20, 2026
AI Assistant
Not every Flutter app is a Flutter-first app. Add-to-App — embedding a Flutter module or app inside an existing iOS or Android codebase — is how teams with years of native investment adopt Flutter incrementally. Historically, that path carried extra tooling friction, especially on iOS, where it inherited CocoaPods whether you liked it or not. What’s new in Flutter 3.44 changes the equation: Swift Package Manager is now the default dependency manager for iOS and macOS, and a new build command packages your Flutter module as a Swift Package your Xcode project can consume directly.
The old add-to-app story
Traditionally, embedding Flutter in an iOS app meant your team needed Ruby, a working CocoaPods installation, and a Podfile alongside your Xcode project. The Flutter module produced an .xcframework that CocoaPods wired into your native app. It worked, but it added a dependency-management stack that many iOS teams had deliberately moved away from — and it was one more thing to break during CI setup or OS upgrades.
SwiftPM by default, with a fallback
Starting with Flutter 3.44, SwiftPM replaces CocoaPods as the default for iOS and macOS, and the Flutter CLI migrates your Xcode project automatically when you build or run. The release post is blunt about the endgame: CocoaPods support “will eventually be removed entirely.”
If one of your dependencies is a plugin that still requires CocoaPods, the CLI prints a warning and temporarily falls back to CocoaPods for those dependencies only. That fallback is the escape hatch that makes gradual ecosystem migration possible — you’re not blocked the day you upgrade Flutter. Package maintainers get an incentive too: packages with SwiftPM support earn additional points in pub.dev scoring. If you maintain an internal plugin, adding a Package.swift (and FlutterFramework as a dependency, if you migrated during the 2024 pilot) moves you onto the supported path.
flutter build swift-package: the headline for add-to-app
The concrete new capability: if you embed Flutter into an existing iOS application, the new command
flutter build swift-packagepackages your Flutter app or add-to-app module as a Swift Package for easy consumption in your native project. Instead of CocoaPods plumbing, your Xcode project adds the generated package the same way it adds any other Swift dependency. The add-to-app iOS project setup docs walk through the integration.
This matters beyond removing CocoaPods. It means the Flutter artifact participates in Xcode’s native dependency graph — dependency resolution, build caching, and versioning behave like the rest of your project rather than like an external build step your team has to babysit.
What the command produces
The Flutter CLI has long had an ios output for add-to-app — the module artifact your Xcode project integrates — but the integration surface was CocoaPods-shaped. With flutter build swift-package, the deliverable is a Swift Package, which means your native team consumes Flutter the same way it consumes any other Swift dependency in the project. For teams standardizing on SwiftPM across their dependency tree (the direction Xcode itself has been pushing), this removes the last special case: Flutter stops being “the thing that needs CocoaPods” and becomes “the thing with a package.”
The same flexibility rationale applies symmetrically. On the native-views-inside-Flutter side, Hybrid Composition++ (opt-in via --enable-hcpp or a manifest meta-data flag) delegates layer compositing to Android itself using Vulkan hardware buffer swapchains and SurfaceControl transactions, rather than routing native views through offscreen buffers or forcing the Flutter engine to process them. The result, per the release notes, is high-performance scrolling, accurate touch input, and reliable SurfaceView support — the historical weak points of platform views. If your app mixes Flutter screens with native maps or webviews, HCPP is the counterpart feature to test in this cycle.
Migration reality check
Two caveats before you plan the move:
- The opt-out is temporary. If SwiftPM breaks your project,
--enable-swift-package-manager: falseinpubspec.yamldisables it, and the team asks you to file a bug with your Xcode project files. But the flag “will eventually be removed,” so treat it as a bridge, not a destination. - Customized lifecycle code may need manual work. Apple’s
UIScenelifecycle requirement (now enforced from iOS 27) means the Flutter CLI auto-migrates only uncustomizedAppDelegatesetups. Add-to-app projects with custom lifecycle handling fall into the migration guide bucket — the one group Flutter flagged for hands-on updates.
On Android, add-to-app remains supported through the existing embedding APIs, and the 3.44 cycle’s Hybrid Composition++ work improves the inverse direction — hosting native Android views (webviews, maps) inside Flutter — by delegating compositing to the OS via Vulkan hardware buffer swapchains and SurfaceControl transactions, opting in with --enable-hcpp or a manifest flag. Teams running hybrid UIs in both directions get a more consistent story across the two mobile platforms.
Should you migrate now?
If you’re mid-add-to-app or starting an integration this year, SwiftPM-first is the path with a future — the default status, pub.dev incentives, and the CLI’s automatic migration all point the same way, and CocoaPods is on a deprecation trajectory. If you’re pinned to CocoaPods by a plugin, check whether the plugin has shipped SwiftPM support (or file that issue with the maintainer); the fallback keeps you moving in the meantime. Either way, flutter upgrade plus a build is the fastest way to see how much of your project the CLI can migrate for you.