In today's rapidly evolving iOS development ecosystem, maintaining efficient and secure dependency management systems is crucial for developers and organisations alike. One significant change on the horizon affects the widely-used CocoaPods package manager, which has been a cornerstone tool for iOS and macOS developers for over a decade. As announced by project maintainer Orta Therox, CocoaPods trunk—the main specification repository—will transition to read-only status in December 2026.
This planned change represents a major shift in how iOS dependencies will be managed moving forward, and requires developers to understand the implications and prepare their projects accordingly.
The transition timeline
The CocoaPods team has established a clear, measured timeline to ensure all developers have ample opportunity to adapt their workflows before the final transition. This extended notice period demonstrates the team's commitment to supporting the developer community through this change.
January 2025 marks the first major notification milestone, when all contributors who have submitted Podspecs will receive emails informing them of the planned transition to read-only status. This early notification provides nearly two years for teams to evaluate their dependency strategies.
In September-October 2026, a second round of notifications will be sent, alerting developers that the transition is approximately one month away. This reminder will help teams finalise any necessary migration plans.
From November 1-7, 2026, a test run of the read-only mode will be conducted, giving automated systems an opportunity to identify potential issues before the permanent change. This trial period represents a crucial testing phase for both the CocoaPods infrastructure and developer workflows.
Finally, on December 2, 2026—strategically scheduled after the American Thanksgiving holiday to avoid disruption during busy periods—CocoaPods trunk will permanently stop accepting new Podspecs. At this point, the GitHub repository will be marked as "Archived," completing the transition.
Impact on exisiting projects
One of the most important aspects of this transition is understanding how it will affect existing codebases and workflows. The good news is that the change has been designed to minimise disruption for current projects.
Existing builds that use CocoaPods will continue to function without interruption. The specifications repository and CDN will remain operational as long as GitHub and jsDelivr continue to exist, which is expected to be for the foreseeable future. This ensures that dependencies already specified in your projects will continue to be resolvable.
However, after December 2026, no new pods or updated versions will be added to the trunk repository. This means developers will no longer receive updates for dependencies managed through CocoaPods trunk, which could eventually impact security and compatibility as the iOS ecosystem continues to evolve.
Teams using CocoaPods with their own specification repositories or those who have vendored their dependencies will experience minimal impact, as these workflows don't rely on the central trunk repository for updates.
Alternative dependency management options
With this significant change approaching, now is an ideal time for development teams to explore alternative dependency management solutions that align with their project requirements and future roadmaps.
Swift Package Manager (SPM) has emerged as Apple's official package management solution and continues to gain adoption across the iOS development community. With tight integration in Xcode and growing support from library authors, SPM represents a natural migration path for many CocoaPods users.
For teams working with React Native, considering tools like npm or Yarn for managing dependencies might provide a more sustainable long-term solution, particularly for projects where JavaScript packages form a significant portion of the dependency tree.
Private specification repositories within CocoaPods will remain a viable option for teams that have invested heavily in the CocoaPods ecosystem. This approach allows organisations to maintain control over their dependencies whilst continuing to leverage familiar CocoaPods workflows.
Carthage offers another alternative for teams seeking a decentralised dependency manager that builds frameworks rather than modifying project structures, which some developers prefer for its minimal interference with project configuration.
Preparing your codebase
To ensure a smooth transition before the December 2026 deadline, development teams should consider implementing a strategic preparation plan for their projects.
Begin by conducting a comprehensive audit of your current dependencies to identify which ones come through CocoaPods trunk. This inventory will help you understand the scope of potential changes needed and prioritise migration efforts.
For mission-critical dependencies, research whether the authors have made their libraries available through alternative package managers like Swift Package Manager. Many popular libraries now support multiple dependency management systems to accommodate developer preferences.
Consider vendoring essential dependencies directly into your projects for maximum long-term stability. Whilst this approach increases repository size, it eliminates reliance on external package management systems altogether.
Develop a migration roadmap that aligns with your release cycles, gradually transitioning dependencies away from CocoaPods trunk with each release. This incremental approach minimises risk and distributes the migration workload over time.
Community support and resources
The iOS development community has always been characterised by strong collaboration and knowledge sharing, which will be particularly valuable during this transition period.
The CocoaPods team remains accessible for questions and concerns about the transition. Developers can reach out via
Community forums such as Stack Overflow, Reddit's r/iOSProgramming, and various Slack channels dedicated to iOS development serve as excellent resources for sharing migration strategies and troubleshooting issues that arise during the transition process.
Open source projects on GitHub often provide examples of successful migrations between dependency management systems, offering practical templates that teams can adapt for their specific needs.
By leveraging these community resources, development teams can navigate this significant change more effectively, sharing knowledge and best practices throughout the transition period.
How to ensure long-term stability for your iOS projects
Whilst the CocoaPods trunk transition represents a significant change in the iOS development ecosystem, proper planning and strategic adaptation can minimise disruption to your workflows and projects. By understanding the timeline, assessing the impact on your specific codebase, exploring alternatives, preparing methodically, and engaging with community resources, development teams can successfully navigate this transition.
At Blue Frontier, we specialise in helping development teams optimise their dependency management strategies and future-proof their iOS applications. Whether you need assistance auditing your current dependencies, creating a migration roadmap, or implementing alternative package management solutions, our team of experts can provide tailored guidance to ensure your projects remain stable and secure through this transition and beyond.
Get in touch to learn more about how we can support your team through the CocoaPods trunk transition.
Review your Podfile and Podfile.lock to identify dependencies that don't specify a custom source. These are the pods that rely on the trunk repository and will be affected by the transition.
According to the announcement, the timeline might be adjusted if compelling reasons arise. Whilst moving the deadline forward is unlikely, there may be flexibility to extend it if necessary. Contact the CocoaPods team directly if you have specific concerns about the timeline.
Whilst Swift Package Manager continues to evolve and has become Apple's official solution, it may not yet offer all the features that CocoaPods provides. Evaluate your specific needs when considering a migration to ensure SPM meets your requirements.
Not necessarily. If your projects use private specification repositories or vendored dependencies, they may continue to function with minimal changes. However, for long-term maintenance and security, exploring alternative dependency management strategies is recommended.
No, existing builds will continue to function. The specifications repository and CDN will remain operational, ensuring that currently specified dependencies remain resolvable. However, you won't receive new updates to those dependencies through CocoaPods trunk.
