Firebase Pushes iOS Developers Off CocoaPods by October

Firebase will stop publishing new versions of its Apple SDK to CocoaPods in October 2026, according to Google’s updated migration guide, giving iOS developers a hard deadline to move onto Swift Package Manager before the wider CocoaPods registry locks down for good (Firebase, 2026).

Key Takeaways

• October 2026 is the cutoff: no new Firebase Apple SDK versions will publish to CocoaPods after that month, per Firebase’s migration guide.
• The move is a reaction to CocoaPods itself: the CocoaPods project announced that its Trunk specs repo goes fully read-only on December 2, 2026. No new pods or podspecs will be accepted after that date.
• Existing CocoaPods installs of Firebase keep building. What stops: new features, performance improvements and critical security patches.
• The cutoff ripples beyond native iOS: FlutterFire, the Firebase Unity SDK and the Firebase C++ SDK all depend on the Apple SDK’s release cadence, so their CocoaPods paths are affected too.
• Google’s recommended replacement is Swift Package Manager (SPM), which every Firebase library already supports, or manual XCFramework installation.

Why now

CocoaPods has been the default iOS dependency manager since 2011, indexing more than 107,000 pods across an estimated 3 million-plus apps. Its maintainers picked December 2, deliberately after the U.S. Thanksgiving weekend, to freeze Trunk to read-only, citing the ongoing cost of running and securing a registry that predates Apple’s own package manager by eight years (CocoaPods blog).

Firebase’s October cutoff lands just ahead of that freeze, so the last CocoaPods builds of the Apple SDK ship while the registry can still accept them. Google started surfacing deprecation warnings in pod install output back in May 2026; this guide is the first firm date attached to the change.

The developer reaction

The react-native-firebase project opened a tracking issue in May, flagging that community wrapper libraries, not just Google’s own SDKs, need their own migration path before the freeze, since React Native and Expo projects leaning on CocoaPods inherit the same deadline. Independent developers documenting their own migrations describe a mechanical but bumpy process: SPM index corruption from cloud-synced project folders, dSYM upload scripts hardcoded to CocoaPods paths, and build tools that silently regenerate a deleted Podfile. None of it is exotic. None of it is free, either, and “October is months away” is the wrong way to read this deadline.

What to do

If your app still installs Firebase via CocoaPods, don’t wait for October to test the swap. Run pod deintegrate, then add Firebase through Xcode’s File > Add Packages using the Firebase GitHub repository, and confirm your non-Firebase pods support SPM too. Mixing CocoaPods and SPM in the same target is a reliable source of duplicate-symbol build errors. Projects on FlutterFire, Unity or the C++ SDK should check their wrapper’s own migration notes, since they inherit this timeline from the Apple SDK underneath them.