CocoaPods Read-Only December 2026 Explained: Trunk Freezes on December 2 — What Stops, What Keeps Working and How to Migrate to Swift Package Manager

Image: Wikimedia Commons / Martin Vorel, CC BY-SA 4.0. Illustrative image: code on a developer's screen.

TL;DR: CocoaPods read-only December 2026 explained: on Wednesday, 2 December 2026, the CocoaPods trunk registry stops accepting new pods and pod versions — permanently. Your existing apps keep building, because every published version stays available. But your dependencies freeze: no new versions, no security fixes through CocoaPods. If your app is still in active development, move to Swift Package Manager now.

Key Highlights

• CocoaPods trunk — the registry behind pod install — stops accepting new pods and pod versions on Wednesday, 2 December 2026, permanently.
• Nothing breaks on 3 December: every published pod version stays installable, and existing apps and CI builds keep working.
• What you lose is updates: no new library versions, no security fixes through CocoaPods after the cutoff.
• Firebase already left — Firebase 13.0.0 (7 October 2026) ships through Swift Package Manager only, so CocoaPods users are capped at Firebase 12.
• Swift Package Manager, built into Xcode, is the replacement — and most popular pods already support it. A test run of read-only mode in early November has already happened.

What happened?

CocoaPods is the dependency manager that has powered iOS and macOS development since 2011 — before Swift even existed. If you have ever typed pod install, you have used it. Its central registry, called trunk, holds more than 107,000 libraries used by more than 3 million apps.

On 11 November 2026, Swift.org published its November digest with a timely reminder from Dave Verwer — co-creator of the Swift Package Index, now at Apple — that trunk stops accepting new pods and pod versions on 2 December 2026. The date is not new: CocoaPods maintainer Orta Therox announced the plan on the CocoaPods blog on 30 November 2024, with a two-year sunset. What is new is the urgency — the deadline is now 18 days away, and the plan's read-only test run in the first week of November (2–6 November, according to the official plan) has already taken place.

The message from both the CocoaPods team and Swift.org is the same: your builds will not break on 2 December, but if you have not switched to Swift Package Manager yet, now is the time.

CocoaPods Read-Only December 2026: What Stops and What Keeps Working

The single most misunderstood part of this change is what "read-only" actually means. CocoaPods is not being deleted. Trunk is being frozen. Here is the split:

What changes on 2 December 2026	Status after the cutoff
Publishing a new pod to trunk	Stops — the server will refuse every new Podspec
Publishing a new version of an existing pod	Stops — pod update will never find a newer version
pod install of versions already published	Keeps working — the Specs repo and CDN keep serving them
Existing apps and CI builds	Keep working — nothing already published is removed
Pods from your own specs repo, :path or :git	Unaffected — they never go through trunk
Security fixes for a pod you use	Stop arriving through CocoaPods — they can only ship as new versions, which trunk will no longer accept

The CocoaPods team says the Specs repository will be archived on GitHub and existing versions will stay available through it and its CDN (jsDelivr) for as long as those services exist. The plan also notes the dates could slip later, but will not be brought forward — so 2 December is the earliest the freeze happens, not a date that might suddenly move closer.

Why is CocoaPods going read-only?

Two reasons, both stated in the plan itself. First, maintenance. CocoaPods has been in maintenance mode since 2024, kept alive by a small team of volunteers. Apple announced Swift Package Manager in 2015, and in the decade since, SPM has become the standard way to manage dependencies everywhere Swift runs — built into Xcode, with no separate tool to install.

Second, security. Trunk is a writable public registry, which makes it a prime target for supply-chain attacks. In 2023, security researchers found three flaws in trunk itself — one of them a critical remote-code-execution hole (CVE-2024-38366) — and CocoaPods patched them that October. The plan's May 2025 update adds that researchers have since abused the scripting capabilities in Podspecs, which is why new pods can no longer use the prepare_command field. Turning trunk read-only removes the attack surface entirely: there is no longer a server that accepts uploads from the public internet. As the plan puts it, converting the Specs repo to read-only will "drastically simplify the security of CocoaPods trunk" — while keeping all existing builds working.

That is exactly why the freeze matters beyond native iOS developers: React Native and Flutter still install their iOS dependencies through CocoaPods, so the freeze reaches every cross-platform team that ships to the App Store.

Image: Wikimedia Commons / Apple Inc., Apache License 2.0. The Swift logo — Swift Package Manager ships with Xcode and is Apple's replacement for CocoaPods.

What it means for your stack

The deadline hits every iOS stack, but the work involved is different for each. Here is where each one stands:

Your stack	Where it stands	What to do
Native iOS (Swift / Objective-C)	SPM is built into Xcode; most popular pods already support it	Remove pods one at a time in Xcode, add the matching Swift package, build and test after each one
React Native	CocoaPods fully supported in 0.88; SPM experimental, planned as the default in 0.89	Audit trunk pods now; try the SPM preview on a branch; React Native 0.81 and Expo SDK 54 already moved core iOS dependencies to precompiled XCFrameworks
Flutter	SPM on by default since 3.44; CocoaPods kept only as a fallback	Upgrade to Flutter 3.44 or later, then find the plugins still on CocoaPods and move them — see our Flutter 3.50 new features explained
Capacitor / Ionic	SPM supported since Capacitor 6	Run the SPM migration assistant (npx cap spm-migration-assistant) from the project root

The Firebase case shows why waiting is costly. Firebase 12.19.0, released 9 September 2026, was the final scheduled Firebase release on CocoaPods. Firebase 13.0.0, released 7 October 2026, ships only through Swift Package Manager and binary downloads — and it needs Xcode 26.2 or later. If your app still installs Firebase through CocoaPods, you are stuck on Firebase 12, with no new features, performance work or critical fixes. React Native Firebase v27, released 19 October 2026, already resolves Firebase 13 through SPM and drops the CocoaPods path entirely.

Why it matters for India readers

India's app-development workforce — from startup teams to freelancers and agencies — builds a large share of its iOS work through React Native and Flutter, the two stacks most exposed to this change. The risk is not a broken build on 2 December; it is a slow freeze. The next time a library you depend on ships a security fix, an iOS-compatibility update or a new Xcode requirement, that update will only exist on Swift Package Manager. Staying on CocoaPods means pinning yourself to pre-cutoff versions and accepting that risk.

The good news is that the fix costs nothing: Swift Package Manager is built into Xcode, and most maintained pods — Alamofire, Kingfisher, SnapKit, RxSwift, lottie-ios and Firebase among them — already publish Swift packages. The work is in your project, not in waiting for libraries to catch up.

How to migrate to Swift Package Manager

You do not have to migrate everything at once — CocoaPods and SPM can coexist in the same project, and moving one library at a time keeps the risk lowest. A practical order:

1. Audit first. Open your Podfile.lock and list every pod that comes from trunk. That is the full scope of the job.
2. Check compatibility. Look each pod up on the Swift Package Index — every package listed there is a SwiftPM package. If a pod is missing, search for an alternative now, while you still have 18 days, rather than discovering the gap during a security incident.
3. Move one pod at a time. Remove one pod, add the matching Swift package in Xcode, build, and test on a real device before moving to the next. Start with the libraries that update most often — Firebase first, if you use it.
4. Keep the fallback. For a pod with no Swift package, install it manually as an XCFramework, or replace the library. Do not leave a single unmaintained pod blocking the whole migration.
5. Delete the Podfile last. Only when the last pod is gone and a full release has shipped clean on SPM alone should you remove CocoaPods from the project. Until then, the mixed setup is the documented path — Flutter, for example, still falls back to CocoaPods for plugins without SPM support.

The migration itself happens inside Xcode, which is worth remembering — Xcode's own tooling keeps moving fast, from GitHub Copilot in Xcode and JetBrains Air to the new SwiftPM defaults. If you work in React Native, our React Native 0.88 explained covers where that framework stands on the same transition.

Should you care?

Yes, if your app is still in active development — migrate now, one pod at a time. Nothing breaks on 2 December, but every update after that date — security fixes included — will only ship through Swift Package Manager. You can wait only if the app is frozen: a shipped app with no planned updates will keep building exactly as it does today. Either way, audit your Podfile.lock this week so the decision is a choice, not a surprise.

FAQs

Will my iOS app stop working on December 2, 2026?

No. Apps that depend on pod versions already published keep building and running exactly as before. The change is that no new pod versions can be published to trunk after the cutoff, so you will stop receiving updates — including security fixes — through CocoaPods.

Do I have to migrate to Swift Package Manager?

Only if you want to keep receiving new versions of the libraries you use. If you are willing to stay pinned to pre-cutoff versions, nothing forces you to move — but you accept the risk of falling behind on iOS, Xcode and platform changes, and of missing security fixes that only ship as new versions.

How do I migrate from CocoaPods to Swift Package Manager?

Audit your Podfile.lock, check each pod on the Swift Package Index, then move one pod at a time: remove it from the Podfile, add the matching Swift package in Xcode, build and test on a device. CocoaPods and SPM can coexist in one project, so migrate gradually and delete the Podfile only after a full release ships clean on SPM alone.

What happens to Firebase if I stay on CocoaPods?

You stay on Firebase 12. Firebase 12.19.0 (9 September 2026) was the final scheduled CocoaPods release; Firebase 13.0.0 (7 October 2026) ships only through Swift Package Manager and binary downloads. New Firebase features, performance work and critical fixes will not reach CocoaPods users.

Takeaway

CocoaPods is not dying on 2 December — it is freezing. Your apps keep building, but your dependencies stop moving. With 18 days left, the sensible move is a one-hour audit: open your Podfile.lock, check each pod on the Swift Package Index, and start with the libraries that update most often. The migration is free, the tools are already in Xcode, and the only thing that gets more expensive with waiting is the first security fix you cannot install.

Already migrating? Start with the stack guide that matches your project — our Flutter 3.50 new features explained covers the Swift Package Manager default that Flutter apps should already be using.

Sources

Swift.org — What's new in Swift: November 2026 Edition (11 November 2026)
CocoaPods Blog — CocoaPods Trunk Read-only Plan (30 November 2024, updated May 2025)
Courier — CocoaPods End of Life: What It Means for iOS, React Native, and Flutter
apex-logic — CocoaPods Read-Only and Firebase 13: Move to SPM Step by Step (updated 22 October 2026)
Velinex Labs — The CocoaPods Sunset: Preparing React Native for December 2026 (updated 13 November 2026)