CocoaPods Trunk Goes Read-Only on December 2: Move to Swift Package Manager

The trunk is closing

CocoaPods trunk becomes read-only on December 2, 2026, after a test run on November 1 to 7. Existing builds keep working, but pods on trunk will accept no new versions after that date. If your iOS or macOS app still has a Podfile, this is your deadline to plan the move to Swift Package Manager.

For developers who have not touched CocoaPods in years, a quick recap: CocoaPods was the dominant dependency manager for Apple platforms for over a decade. Trunk is its central registry, the place where pod authors publish new versions. Read-only does not mean deleted. Your existing Podfile.lock will still resolve, your CI will still install the same versions, and your app will still build. What stops is new releases. The moment a library you depend on ships a fix only through Swift Package Manager, or a new library launches without a podspec at all, you will be stuck.

Why this is happening now

Apple has spent years steering developers toward Swift Package Manager, which ships inside Xcode and needs no Ruby, no separate tool and no third-party registry. Most actively maintained libraries already support both, and many new ones only support SPM. CocoaPods maintenance has slowed as its maintainers moved on, and keeping a central registry running for a shrinking audience is a cost someone has to pay. The read-only decision is the graceful version of a shutdown: nothing breaks today, but the direction is final.

The November 1 to 7 test run matters more than it looks. That is your window to discover whether your build survives a read-only trunk in practice, before the real date. Run your CI against it, check that pod install still works from cache and mirrors, and confirm that no part of your pipeline tries to publish or update trunk versions. Finding out on December 3 is a worse experience.

How to migrate without breaking your app

Start with an audit. List every pod in your Podfile and check whether each one already supports Swift Package Manager. Most will. For those that do, migration is usually straightforward: add the package in Xcode, remove the pod, build, and run your tests. Do it one dependency at a time, not all at once, so a failure points at a single culprit.

For pods that do not support SPM, you have three options, in order of preference:

• Find the maintained fork or replacement. Many abandoned pods have community forks with SPM support.
• Vendor the code. Copy the source into your project directly if the license allows it. This is unglamorous but reliable for small, stable libraries.
• Keep CocoaPods for that one dependency. A mixed setup works, but it is technical debt with a visible expiry date, so document it and revisit it.

Watch out for the classic migration traps: resource bundles that load differently under SPM, build settings that CocoaPods used to inject automatically, and binary pods that need an XCFramework instead. Run your full test suite after each change, and test on a real device, not just the simulator, before merging.

What this means for the Apple ecosystem

CocoaPods going read-only is the end of an era, but it is also a consolidation that most developers will welcome once the migration pain fades. One fewer tool in the chain means fewer Ruby version fights, fewer pod install mysteries, and a dependency story that works out of the box in Xcode. That matches the direction of Apple's current tooling, from TypeScript 7.1 beta reshaping toolchains elsewhere to GitHub's AI scan catching pull-request bugs that older tools miss.

If you maintain a library, publish an SPM-compatible release before December, and say so clearly in your readme. If you maintain an app, start the audit this week. December 2 sounds far away until you count the dependencies, the test cycles and the App Store review in between. The developers who will be fine are the ones who treat this as a planned migration, not a December surprise.