CocoaPods trunk goes read-only on December 2: what stops, what keeps working, and how to read your Podfile.lock

CocoaPods trunk, the service that accepts new podspecs, stops accepting them on December 2, 2026. A trial run of read-only mode comes first, from November 1 to 7. Both dates are in the CocoaPods announcement, which I re-read today.

Most of the discussion I see is about whether builds break. They don't, and the announcement says so. The more useful question is a different one: which of the pods in your lockfile will never get another release, and where will their next release come from?

What the announcement says

The plan has three parts:

• A test run, November 1 to 7, 2026. In the post's words: "I will trigger a test run, giving automation a chance to break early". If your CI publishes pods with pod trunk push, that week is when you find out what depends on it.
• The switch, December 2, 2026. After that, "no new versions or pods will be added to trunk."
• Existing builds. "This will keep all existing builds working". The Specs repository stays readable, so pod install keeps resolving the versions already published.

So nothing in your app changes on December 2. What changes is the future: a pod that only ships through trunk gets no new version after that date. A bug fix or a security fix released later has to reach you some other way, usually as a Swift package.

Firebase leaves earlier

One publisher is ahead of the deadline. The Firebase migration page says Firebase "will stop publishing new versions to CocoaPods in October 2026", and that "Firebase 12 is the final major version published to CocoaPods." Versions 12 and earlier stay installable.

This matters for apps that never list Firebase in their own Podfile. GoogleUtilities, nanopb, PromisesObjC and GoogleDataTransport usually arrive as Firebase dependencies, and they stop with it.

A real lockfile, read pod by pod

To see what this looks like on an actual project, I ran a small open-source CLI I wrote, podexit, on the native iOS fixture in its repository: a Podfile with Alamofire, Kingfisher, SnapKit, Lottie, MBProgressHUD, Firebase Analytics and Crashlytics, Google Sign-In, a git pod and a local path pod. The lockfile was resolved by CocoaPods 1.16.2. In the project folder:

npx @mcamdali/podexit

Excerpt of today's output (podexit 0.1.2, exit code 0):

podexit 0.1.2 · CocoaPods trunk goes read-only on 2026-12-02 (trial run 2026-11-01 to 2026-11-07)
Builds keep working: pods already on trunk stay installable after December 2, 2026. Trunk only stops accepting new versions.

Podfile.lock  native iOS app · 28 pods, 10 in the Podfile

  POD                          LOCKED     LATEST ON TRUNK  UPDATES               SWIFT PACKAGE   PULLED IN BY
  FirebaseAnalytics            12.19.0    12.19.0          capped at 12.x        yes (Firebase)
  GoogleAppMeasurement         12.19.0    12.19.0          capped with Firebase  unknown         FirebaseAnalytics
  GoogleUtilities              8.1.4      8.1.5            capped with Firebase  yes             AppCheckCore +8
  Alamofire                    5.12.2     5.12.2           frozen after Dec 2    yes
  GoogleSignIn                 9.2.0      10.1.0           frozen after Dec 2    yes
  Kingfisher                   8.13.0     8.14.0           frozen after Dec 2    yes
  GTMSessionFetcher            3.5.0      5.3.1            frozen after Dec 2    yes             GTMAppAuth +1

  11 frozen on trunk · 15 capped by the publisher · 2 not affected
  25 pods with a Swift package · 0 without · 2 unknown

Four things in that table are worth reading slowly.

The Podfile lists 10 pods; the lockfile has 28. Most of the exposure is in transitive pods. GoogleUtilities is pulled in by nine others.

"Capped" and "frozen" are different dates. The 15 Firebase pods and their dependencies stop at 12.x from October 2026. The 11 frozen pods (Alamofire, Kingfisher, SnapKit and others) can still get a release on trunk until December 2, then no more.

Some locked versions are already far behind. GoogleSignIn is locked at 9.2.0 while trunk has 10.1.0; GTMSessionFetcher at 3.5.0 against 5.3.1. For those pods, moving to Swift Package Manager is also a major-version upgrade. Plan the testing time for it.

"Unknown" comes with a reason. For GoogleAppMeasurement, the JSON report says: "The podspec points to dl.google.com, not a GitHub repository." podexit checks for a Package.swift only in GitHub repositories, so anything hosted elsewhere is marked unknown instead of guessed.

The two "not affected" pods are the git pod and the local path pod. They never came from trunk, so the switch does not touch them.

What I would do this week

1. Before November 1: check whether any CI job runs pod trunk push. The trial week is the announcement's chance for that automation to fail early.
2. List your capped pods first. If you use Firebase through CocoaPods, its last major there is 12, and new versions stop this month.
3. For each frozen pod with a Swift package, compare the version you lock with the latest one. A small gap is a quick move; a major gap is a project.
4. Look at every "unknown" by hand. Binary pods and pods hosted outside GitHub need a check on the vendor's own page.
5. Leave local and git pods for later. The trunk switch does not affect them.

Limitations

• podexit reads and reports. It does not migrate anything, and it does not install anything into your project.
• "Swift package: yes" means the upstream repository has a Package.swift, also at the version you lock where it says so. It does not prove the package offers every subspec you use; check the products when you move.
• The lookups need the network (CocoaPods CDN, trunk and GitHub). Answers are cached for 24 hours, and --offline uses the cache only.
• It is new (0.1.2) and has no user data yet. Treat the output as a checklist, not as an audit.

Try it

Run these in the folder that has your Podfile.lock, or in a Flutter or React Native app root; podexit also looks in ios/ and example/ios/. Node.js 22.12 or later is required.

npx @mcamdali/podexit
npx @mcamdali/podexit --format markdown --output podexit.md
npx @mcamdali/podexit --offline

The second command writes a Markdown report you can paste into a pull request; it starts with the trial-run dates and the summary line ("11 frozen on trunk · 15 capped by the publisher · 2 not affected" for the fixture above).

If your app also has to build with the iOS 27 SDK, the companion piece "Built with the iOS 27 SDK, a UIKit app without a scene stops at launch" covers the other deadline.

Repository: github.com/muhittincamdali/podexit (MIT).

Muhittin Camdali is a mobile engineer (iOS, Flutter, React Native) and the author of podexit.