The CocoaPods Trunk Goes Read-Only in December: A Swift Package Manager Checklist for Flutter Teams

Flutter 3.50 has been out for three days, and the release notes are dominated by native interop and WebAssembly numbers. Buried in the platform section is the item that will cause more support tickets than either: with the CocoaPods trunk becoming read-only in December 2026, Flutter's temporary CocoaPods fallback is winding down, and disabling Swift Package Manager now produces a warning on every CLI command.

That warning is the framework's way of saying the grace period is nearly over. Swift Package Manager became the default dependency manager for iOS and macOS apps back in Flutter 3.44. For apps that were created or migrated since then, nothing about December changes. For everyone else, the deadline is now close enough to schedule rather than plan.

What Read-Only Actually Means

A read-only CocoaPods trunk still serves existing pods. It stops accepting new ones and stops accepting new versions of existing ones. In practice that means an app that resolves its iOS dependencies through CocoaPods can keep building with whatever versions are already published, but it cannot pick up a new plugin release, and it cannot publish anything of its own.

For app teams the failure mode is slow rather than sudden. Builds keep working until a dependency needs an update, and then the update is unavailable. That is worse than a hard break, because it surfaces weeks later inside an unrelated piece of work, usually during a security patch.

For plugin authors the situation is more direct. A plugin that ships only a podspec is publishing into a channel that is closing. The Flutter tooling already reflects this: unmigrated plugins receive lower pub.dev scores, which affects discovery long before it affects a build.

The Migration Path Most Teams Already Have

The good news is that the migration is mostly automatic. Running flutter build ios or flutter build macos with Swift Package Manager enabled uses the existing podspec to generate a Swift package, with a generated Package.swift placed inside the ephemeral build directory rather than in version control. Most plugins need no source changes at all.

The plugins that do need work are the ones that do something unusual: custom build phases, script phases that run during pod install, or resource handling that assumes a podspec layout. Those are the cases worth auditing before December rather than after.

• Run a build with Swift Package Manager enabled and check that every plugin resolves without falling back to CocoaPods
• Grep the project for Podfile and podspec references that are no longer required, particularly in CI scripts that still run pod install
• Check whether any dependency pins a version that was only ever published to the trunk after the freeze date

Flutter is not removing the CocoaPods path in 3.50. It is warning about it. That is a deliberate distinction: the tool continues to work, but the framework no longer treats the fallback as a supported long term state, and the warnings exist so that the eventual removal is not a surprise.

There is a second warning in the same release that Intel Mac users will see. Flutter now warns when the host is an x86_64 Mac, and flutter config --enable-macos-arm64-only switches builds to Apple Silicon only. For teams with older build machines, that is a second piece of hardware debt arriving on the same schedule.

Where Pigeon and FFIgen Fit

Teams that have already adopted Pigeon for platform channels have a smaller problem than they think. Pigeon generates both the Swift and Kotlin sides of a contract from a single definition file, and version 30 and later can sit on top of direct native interop through SwiftOptions(useFfi: true) and KotlinOptions(useJni: true). The dependency management layer and the interop layer are separate concerns, but the migration work overlaps.

shared_preferences is the reference implementation to read. It has already been migrated to Swift Package Manager and to the direct interop path, so its repository shows what a maintained plugin looks like after both changes. For an in-house plugin, that is a better template than any migration guide.

The plugin ecosystem is in better shape than the deadline suggests. Most of the widely used packages made the switch during 2026, and the ones that did not are visible through their pub.dev scores. The remaining risk is concentrated in the long tail: internal plugins, forks that nobody maintains, and dependencies pulled in by a single feature that has not been touched in a year.

December is six weeks away, which is enough time to find and fix the stragglers but not enough to defer the audit to the next release cycle. The cheapest version of this work is a build with Swift Package Manager enabled on a branch, followed by a look at anything that still resolves through the trunk.