CocoaPods end of life: here's what to do

On December 2, 2026, CocoaPods trunk becomes permanently read-only. After that date, the central registry that has shipped iOS dependencies for more than a decade stops accepting new pod versions and new podspecs.

CocoaPods isn't being deleted. Existing pods stay where they are. Your app will keep building. But the ecosystem around it is moving, and the ripples reach further than they look.

The CocoaPods end of life affects every iOS app that uses pods: native Swift and Objective-C projects, React Native apps with their ios/Podfile, Flutter apps with their plugin-driven pod graph, and any wrapper SDK that depends on the Apple ecosystem underneath. If you ship to iOS, this deadline is on your roadmap whether you've looked at it yet or not.

Here's what's actually changing, which libraries you should expect to migrate, how the three big mobile stacks are affected, and a tight playbook for moving off CocoaPods without breaking the things you ship.

TL;DR

• December 2, 2026: CocoaPods trunk becomes permanently read-only. No new pod versions or podspecs can be published.
• October 2026: Firebase stops publishing new Firebase Apple SDK versions to CocoaPods. Other large vendors are following.
• Existing CocoaPods versions stay available. Your current app will keep building.
• Swift Package Manager (SPM) is the default replacement, with manual XCFramework installation as a fallback.
• CocoaPods powers more than 107,000 libraries across more than 3 million apps. The migration affects native iOS, React Native, and Flutter projects.
• Most popular pods (Alamofire, Kingfisher, SnapKit, RxSwift, lottie-ios, Firebase, Courier) already support SPM. The migration is the work, not the availability.
• If your app depends on push notifications, treat this as a notification reliability deadline, not a routine dependency cleanup.

The CocoaPods timeline

There are two related moments to plan around: vendor cutoffs and the trunk lock.

Vendor cutoffs and the trunk lock aren't the same event. Firebase's October date sets a hard ceiling on Firebase Apple SDK versions you can install through CocoaPods. As Firebase's migration FAQ puts it: "We chose October to ensure the final versions published to CocoaPods are stable before the registry locks in December." The December trunk lock sets the same ceiling on the entire ecosystem. The CocoaPods team has cited the security and maintenance burden of a writable public registry as the driving reason for the change.

The pods most likely to affect you

Here are the popular pods you're most likely using and need to plan a migration for.

Networking

• Alamofire: the de facto Swift networking library
• Moya: a higher-level abstraction built on Alamofire

Image loading and caching

• Kingfisher: pure-Swift image downloading and caching
• Nuke: alternative image pipeline with extensive plugins

UI and layout

• SnapKit: Swift DSL for Auto Layout
• IQKeyboardManager: drop-in keyboard avoidance
• SkeletonView: loading placeholders
• SwiftMessages and SwiftEntryKit: in-app toasts and alerts

Animation

• lottie-ios: After Effects animations rendered natively

Reactive and async

• RxSwift and RxCocoa: reactive streams (Apple's Combine is the native alternative)
• PromiseKit: promise-based async

Logging and utilities

• CocoaLumberjack: structured logging framework
• SwifterSwift: Swift extension library
• KeychainAccess: Keychain wrapper
• Reachability.swift: network reachability

Data and charts

• Charts (and the DGCharts successor): the iOS port of MPAndroidChart

Firebase Apple SDK family

• Firebase, FirebaseMessaging, FirebaseAnalytics, FirebaseCrashlytics, FirebaseAuth, FirebaseFirestore, FirebaseRemoteConfig, FirebasePerformance, and the rest of the suite. Firebase has the most publicized migration deadline, but it's one vendor among many.

The good news: most of these libraries already publish to Swift Package Manager (SPM). The migration work is on your project, not on the upstream library. The exception is a long tail of smaller pods that haven't added SPM support and may not, which is where manual XCFramework installation or replacement becomes the conversation.

What it means by platform

Native iOS

If your app has a Podfile, a Podfile.lock, and a generated .xcworkspace, you're squarely in scope. Watch for extensions (notification service, share, widgets) and test targets that depend on pods. SPM doesn't propagate to extension targets automatically the way CocoaPods sometimes did, so each target needs its own dependency review.

React Native

React Native apps use CocoaPods under the hood for iOS native modules. If you've ever run cd ios && pod install, you have a CocoaPods dependency graph whether you wrote it yourself or not.

The places to look:

• ios/Podfile and ios/Podfile.lock
• @react-native-firebase/* and other native modules
• Custom native modules that ship podspecs
• CI steps that run pod install before xcodebuild

React Native Firebase has been moving toward SPM support, and React Native itself has been reducing its CocoaPods coupling. Verify the current versions of both before planning a migration window.

Flutter and FlutterFire

Flutter ships with a CocoaPods-driven iOS layer. The Flutter tool generates ios/Podfile from your plugin set, and each Flutter plugin that ships native code typically publishes a podspec.

FlutterFire is the most prominent example. The Firebase team has said that if you're on Flutter, you can ride the SDK upgrade path, because the latest FlutterFire releases migrate the underlying Apple dependency manager to Swift Package Manager. That handles Firebase, but it doesn't handle the rest of your ios/Podfile. Plugins outside the FlutterFire family still resolve through CocoaPods, and any internal native code you maintain probably does too.

Unity, C++, and other wrapper SDKs

Distributions that wrap the native Firebase Apple SDK, including the Firebase Unity SDK and Firebase C++ SDK, follow the same downstream pattern. The wrapper migrates when the upstream Apple SDK migrates. If you manage iOS dependencies through CocoaPods inside a Unity or C++ project, you're subject to the same trunk read-only deadline.

Your migration options

You have four practical options.

One thing to know about mixing dependency managers: mixing CocoaPods and SPM in the same target can produce dependency cycles and build errors. Doing it across different targets in the same workspace is fine, and most migrations end up there. SPM in your main app target, leftover CocoaPods in a secondary target, until you can finish the move. Same-workspace is OK; same-target is the part that breaks.

The migration playbook

The steps below apply to native iOS projects migrating to SPM. React Native and Flutter are each on their own migration timelines, and neither has a clean end-to-end playbook yet. We'll cover those separately as the tooling stabilizes.

Use this as a tight four-phase checklist. Treat each phase as a gate.

1. Audit

• Inventory every Podfile, Podfile.lock, and .xcworkspace in your repos.
• List every pod, pinned version, and the target it links to.
• Check Build Phases for run scripts that reference PODS_ROOT (Crashlytics dSYM upload, Firebase Performance instrumentation, custom resource scripts).
• Check Other Linker Flags for -ObjC, especially if you use Firebase Analytics.
• Search CI configs for pod install, pod update, bundle exec pod install, and CocoaPods caching steps.
• Confirm whether each pod offers a Swift Package Manager target.

2. Migrate

• Close Xcode, run pod deintegrate, and remove the generated .xcworkspace.
• Open the .xcodeproj directly. Add packages through File > Add Package Dependencies.
• For each pod, add the equivalent SPM product and link it to the right target.
• For pods without SPM support, drop in a manual XCFramework or move to a replacement library.
• Update any build phase script paths that previously pointed inside Pods/.
• Use the current major version from each library's release notes. Don't copy a pinned version from a blog post (including this one).

3. Fix CI

• Replace xcodebuild -workspace YourApp.xcworkspace with -project YourApp.xcodeproj.
• Resolve packages as a separate step before the build so dependency fetches don't eat into your build timeout:

xcodebuild -resolvePackageDependencies \
  -project YourApp.xcodeproj \
  -scheme YourApp

• Cache the resolved SourcePackages directory between CI jobs.
• Update Fastlane, Bitrise, GitHub Actions, or Xcode Cloud configs that assume .xcworkspace exists.
• Update any dependency review job that previously watched Podfile.lock.

4. Smoke test

• Run a clean build locally and in CI from a fresh checkout.
• Test the features that depend on the migrated SDKs end to end on a physical device.
• For apps with push notifications, run a full notification smoke test: APNs registration, FCM or APNs token issuance, foreground delivery, background delivery, silent push (content-available: 1), cold-start tap routing, and any analytics callbacks you depend on.
• Watch crash reports and logs for the first 48 hours after release.

The migration isn't finished when the app builds. It's finished when the runtime paths you care about have been verified on the new dependency graph.

Why this is a notification reliability issue

Push notifications run through the longest dependency chain in your app. APNs registration, token issuance, FCM mapping if you use Firebase, backend targeting, iOS display rules, tap handling, and analytics callbacks all sit on top of the SDK you installed through your dependency manager.

When the dependency manager itself starts aging out from under you, the rest of that chain gets quietly older too. Pinned SDKs miss APNs fixes. iOS version upgrades surface bugs that have already been fixed in newer SDK versions you can't install. Notification analytics drift. None of this looks like a build error. It looks like missing notifications.

This is one of the reasons we treat notification infrastructure as production infrastructure. Courier's own iOS SDK still publishes to both CocoaPods and SPM today, so we're walking this same migration path. If push is a critical channel for your product, the iOS SDK handles APNs token syncing automatically through CourierDelegate and lets you route across push, email, SMS, in-app, and chat so a single SDK or registry change doesn't become a delivery outage.

If you want the deep dive specifically on Firebase Cloud Messaging, our Firebase CocoaPods migration guide for iOS push walks through FirebaseMessaging, Notification Service Extensions, and the swizzling forwards.

Frequently asked questions

Is CocoaPods dead?

No. CocoaPods continues to exist, existing pods remain installable, and the tooling keeps working. What's changing is that CocoaPods trunk becomes read-only on December 2, 2026, so the central registry stops accepting new pod versions and new podspecs.

When does CocoaPods go end of life?

CocoaPods trunk is scheduled to become permanently read-only on December 2, 2026. A read-only test run is planned for November 1-7, 2026.

What's replacing CocoaPods?

Swift Package Manager is the default replacement for most Apple projects. Manual XCFramework installation is the fallback for libraries that don't ship SPM support.

Will my iOS app stop working?

No. Apps that depend on existing pod versions keep building and running. The change is that you won't receive new versions of those pods through CocoaPods after the trunk lock, and many vendors will stop publishing to CocoaPods before then.

Can I still run pod install after December 2026?

Yes. pod install and pod update continue to resolve against versions that were published to trunk before the read-only date. You only lose the ability to publish or fetch newly registered versions.

Do I have to migrate to Swift Package Manager?

If you want to keep receiving new versions of libraries that move to SPM, yes. If you're willing to pin on pre-cutoff versions, no, but you accept the risk of falling behind on iOS, Xcode, and platform changes.

Is Swift Package Manager better than CocoaPods?

It's where the ecosystem is going. SPM is built into Xcode, requires no extra tooling, and integrates cleanly with Swift's build system. CocoaPods is more flexible in some edge cases, particularly around build configuration, but the SPM workflow is usually simpler day to day.

What happens to my Podfile after CocoaPods goes read-only?

Your Podfile and Podfile.lock keep working. pod install keeps resolving against versions that were published before the cutoff. Your builds don't break. You're pinned to those versions, though, and you won't get new releases through CocoaPods.

How do I migrate from CocoaPods to Swift Package Manager?

Close Xcode, run pod deintegrate from your project directory, and delete the generated .xcworkspace. Open the .xcodeproj in Xcode, then add your dependencies through File > Add Package Dependencies. Link each SPM product to the correct target, update build phase scripts that referenced Pods/, and run a clean build. The migration playbook section above covers this in detail.

Is CocoaPods still safe to use?

Existing pods remain installable, and the move to read-only actually reduces the security surface by closing the writable registry. The CocoaPods team has cited supply-chain risk as a key reason for the change. You're not taking on new security risk by continuing to resolve existing pod versions.

Does this affect React Native and Flutter apps?

Yes. Both stacks use CocoaPods under the hood for iOS dependencies. React Native projects ship an ios/Podfile for native modules, and Flutter projects generate one from the plugin set. The trunk read-only date applies to those pods the same way it applies to native iOS apps.

Wrapping up

The CocoaPods end of life isn't a single dramatic outage. It's a slow shift from "the default way to install iOS dependencies" to "the legacy way." The risk is that you don't notice you've fallen behind until an iOS or Xcode change exposes it.

Three things worth doing this quarter:

1. Inventory every Podfile across your iOS, React Native, and Flutter projects.
2. Identify which of your top dependencies already publish to Swift Package Manager (most of them).
3. Pick the next release where you can land the migration without rushing it.

CocoaPods served the iOS ecosystem for more than a decade. The libraries it helped distribute aren't going anywhere. Where they live is moving, so your build system needs to move with them.

Related resources:

• CocoaPods trunk read-only plan
• CocoaPods support and maintenance plans
• Firebase migration guide for CocoaPods
• Swift packages in Xcode
• Firebase CocoaPods migration guide for iOS push notifications
• Courier iOS SDK documentation