Safeguard
Developer Tools•

CocoaPods trunk goes read-only: what should iOS teams do now?

CocoaPods trunk plans to stop accepting new podspecs on 2 December 2026. Existing builds keep working. Here is what iOS teams should check and plan now.

Safeguard Security Team
3 min read

According to the CocoaPods team, trunk is planned to stop accepting new podspecs on 2 December 2026. Existing builds keep working. The practical effect is that pods you rely on will not publish fixes through trunk after that date, so check which of your dependencies are unmaintained or have moved.

What the plan says

The CocoaPods blog describes a switch to a read-only trunk. New podspec submissions would be denied at the server level, and the CocoaPods Specs repository on GitHub would be marked as archived. The post says this "will keep all existing builds working."

The stated timeline:

  • A test run of read-only mode is planned for 1 to 7 November 2026, so automation breaks early.
  • Trunk stops accepting new podspecs permanently on 2 December 2026.
  • The author says the dates are not fixed and could move later, but are unlikely to move earlier.

People using their own specs repositories or vendored dependencies are described as unaffected. Check the blog post for the current dates before you plan around them.

What it means for security

A frozen registry is not a vulnerability. The risk is indirect. If a pod has a security fix and its maintainer would have published it to trunk, that route closes. You would need to take the fix from the source repository, a fork, or a different package manager.

Pods that are already abandoned are the real concern. They have no fix coming whether or not trunk is open, and a read-only trunk makes that visible.

Steps to take this month

  1. Run pod outdated and list every pod with no release in a long time.
  2. For each, check whether the library has a Swift Package Manager release, since many projects publish both.
  3. Note any pod pulled by a :git source in your Podfile. Those already bypass trunk and need their own review.
  4. Decide per pod: stay, switch to a Swift package, vendor it, or replace it.
  5. Make sure the lock file is committed so your current versions stay reproducible.
  6. Plan the move with a security lens. Migrating from CocoaPods to SwiftPM without losing track of dependencies walks through it.

Try it yourself

Click through it at your own pace, or open it full screen. Notice how each package carries its own version and advisory status.

Safeguard builds an SBOM and scans your dependencies for known vulnerabilities, and you can run a free scan at gold.safeguard.sh/scan to see what your own project pulls in.

Quick check

Will my app stop building on 2 December 2026?

Per the CocoaPods announcement, no. Existing builds keep working. New versions and new pods will not appear on trunk after the switch.

Do I have to leave CocoaPods?

Not by this announcement alone. You do need a plan for any pod that will not receive updates.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.