TLDR: In two years we plan to turn CocoaPods trunk to be read-only. At that point, no new versions or pods will be added to trunk.
Last month I wrote about how CocoaPods is currently being maintained, I also noted that we were discussing converting the main CocoaPods spec repo "trunk" to be read-only:
We are discussing that on a very long, multi-year, basis we can drastically simplify the security of CocoaPods trunk by converting the Specs Repo to be read-only. Infrastructure like the Specs repo and the CDN would still operate as long as GitHub and jsDelivr continue to exist, which is pretty likely to be a very long time. This will keep all existing builds working.
I plan to implement the read-only mode so that when someone submits a new Podspec to CocoaPods, it will always be denied at the server level. I would then convert the "CocoaPods/Specs" repo to be marked as "Archived" on GitHub which should cover all of our bases.
Making the switch will not break builds for people using CocoaPods in 2026 onwards, but at that point, you're not getting any more updates to dependencies which come though CocoaPods trunk. This shouldn't affect people who use CocoaPods with their own specs repos, or have all of their dependencies vendored (e.g. they all come from npm.)
Timeline
My goal is to send 2 very hard-to-miss notifications en-masse, and then do a test run a month before the final shutdown.
Jan 2025
I will email all email addresses for people who have contributed a Podspec, informing them of the impending switch to read-only, and linking them to this blog post.
September-October 2026
I will, again, email all email addresses for people who have contributed a Podspec, informing them of the impending switch to read-only, and linking them to this blog post, noting that they have roughly a month before we do a test run of going read-only.
November 1-7th 2026
I will trigger a test run, giving automation a chance to break early
December 2nd 2026
I will switch trunk to not accept new Podspecs permanently. This is a Wednesday after American Thanksgiving, so I think folks won't be in rush mode.
These dates are not set in stone, and maybe someone out there has a good reason for us to amend the timeline. I don't think I'm amenable to moving it forwards, but within reason there's space for backwards.
If you have questions, you can contact the team via [email protected], me personally at [email protected] or reach out to me via Bluesky: @orta.io.
TLDR: We're still keeping it ticking, but we're being more up-front that CocoaPods is in maintenance mode.
CocoaPods is about 13 years old now, and the landscape of iOS development has changed a lot in that time. I remember the fragmented islets of small shared libraries (like: ASIHTTPRequest, Three20, SBJson, SSToolkit, iCarousel) with tricky upgrade instructions and complicated build setups. CocoaPods simplified that process enough that it turned into the de-facto way to share code in the iOS and Mac community.
In 2015, Apple announce that the CocoaPods project had been Sherlocked because they were going to be creating their own package manager: Swift Package Manager. This move effectively took all the wind out of the sails of CocoaPods, slowing active development of the project as competing with Apple on their own turf is rarely a battle worth your volunteer hours.
Since Swift Package Managers announcement 9 years ago, members of the core team have individually had reasons for continual maintenance: a sense of duty, being employed to work on libraries or apps which use CocoaPods, working on build infra for large projects where CocoaPods is a key part of the build process or just a love of the community.
However, with time - these links become more tenuous too, jobs change, people move to new ecosystems and we've slowly been moving CocoaPods to an place where work only happens when something external causes it. That could be security issues like I've reported the last few years on the blog, or Xcode breaking changes which require us to tweak some settings and make a new build.
If CocoaPods' only audience were native Cocoa developers, CocoaPods' usage should be on the decline, however, that is not the case. The popularity of React Native and Flutter have ensured that most metrics of usage/traffic have been steadily rising over time.
This puts CocoaPods in a strange place, a lot of the maintainers don't use it, Apple have been maintaining a replacement for 9 years and the new users of the project barely even know that CocoaPods exists or what it does.
So, we concluded we need to figure out what is going on with the project and how we have been treating it as maintainers over the last few years.
How CocoaPods Is Maintained
Strictly speaking, we don't plan on changing how we're maintaining CocoaPods. We're just going to start being clear how CocoaPods has been maintained:
- We will make sure to handle systemic security issues to trunk
- We will aim to make at least 2 releases a year to keep up-to-date with Xcode updates
- We will aim to look at support requests for trunk every 6 months
- We will keep the website infrastructure from not falling over completely
- We are open to PRs which make CocoaPods more future-friendly
What we will not be doing:
- We don't actively follow GitHub issues as a support avenue for individuals
- We aren't planning on active CocoaPods development in terms of new features
- We aren't going to make guarantees about handling PRs from people adding new features, or application-level bugs
New contributors
This is where people would normally say "If we had more volunteers or money etc" but we're not sure that this would help, the skills of maintaining build tooling in Ruby have grown increasingly less relevant over the years to the point that the overlap between "knows how to handle an Xcode project" and "knows what's going on in a complex ruby project" is pretty slim.
We're open to the idea that multiple people who are well motivated to do the necessary volunteer work may be out there, but the search, training and mentoring is also a big ask for existing folks who have little enough time for the project.
Long term plans
Read-only Specs
We are discussing that on a very long, multi-year, basis we can drastically simplify the security of CocoaPods trunk by converting the Specs Repo to be read-only. Infrastructure like the Specs repo and the CDN would still operate as long as GitHub and jsDelivr continue to exist, which is pretty likely to be a very long time. This will keep all existing builds working.
At least for projects like React Native, this could be fine as-is, as most of their libraries come via npm instead of the Trunk, I can't talk to how Flutter's ecosystem works as I have no exposure to it.
We'd make the Specs repo read-only by offering a date when Trunk (our CocoaPods Specs repo authentication server) will be disabled. As trunk is the main target in a supply-chain attack, this would nix all the key issues there. I think we'd be open to this changing if there is a popular alternative client for the Specs Repo was maintained and used by a reasonable number of the community.
We would have a specific blog post with a comprehensive plan if/when this idea settles with us, and to be very explicit: the announced date would be years away.
I use CocoaPods as a Hidden Abstraction in My Framework
E.g. I maintain Unity, React Native, Flutter etc. A lot of these projects will (and should) be migrating to Swift Package Manager with time. As specified above, we are not breaking anything but bugs you may raise are unlikely to get fixed.
If you run these sorts of frameworks and are commercially exposed here, then we're open to chatting - I think no-one on the current team is interested in working on this full time but that doesn't mean we can't find ways to have others who consider this a part of their job role taking over parts of what keeps CocoaPods ticking. You can mail all of us at [email protected] or me personally at [email protected] if you prefer.
Plodding on
Long term maintenance of public infra is often a long grind with the occasional thanks, so I want to try leave this on a "thanks" and give a shout out of all the folks who have been helping to keep the project alive: Eloy, Fabio, Danielle, Dimitris, Eric, Samuel, Paul, Igor, Boris, Florian, Keith, Karla, Emma, Marin, Michele, Joshua, Delisa, Kyle, Olivier, Hugo, Nate, Muhammed, Ben, and Marius . Plus, anyone who ended up in the CocoaPods Slack!
Over the last month, security researchers at evasec.io have been reached out to us about three separate vulnerabilities in CocoaPods Trunk (the server which handles updates to Pods). We've been working with evasec to patch these issues as they come up. Looking at all three combined, I felt we needed to reset all user sessions again, which is why I'm writing on the blog post instead of working on Puzzmo which just shipped this week.
There are three key issues reported against Trunk, which were promptly fixed:
- 1. It was still possible to use the 'claim your pod' process to take over a Pod when someone had removed all prior maintainers from it
- 2. The email which is sent out to verify your email address can be tricked to change to link to a third party
- 3. The part of trunk which verifies your email address could be used to execute shell commands on the trunk server
Being able to execute arbitrary shell commands on the server gave a possible attacker the ability to read our environment variables, which could be used to write to the CocoaPods/Specs repo and read the trunk database. Being able to trick people into clicking on a link which would take them to a third party site could be used to steal their session keys. I can't guarantee neither of these happened, and I'd rather be on the safe side.
This means you will need to log in again to trunk again to deploy any new Podspecs. If you have automated deployment to CocoaPods working with a stored ENV VAR right now, this will break, and you will need to pod trunk register again and replace your COCOAPODS_TRUNK_TOKEN. We're sorry, I know that sucks, but it also guarantees that you are the only person with write access to your pods.
If you are not a pod author, you do not need to do anything.
evasec.io are still in the process of writing up the full technical details of how the exploits worked, so I'll both update this post with links to their write-ups when they are ready, as well as do a new blog post with the details at a higher level to describe how they work to folks who are not intimate with server architectures.
Read on →
I'm very happy to announce that Emerge Tools is now sponsoring the web hosting costs of CocoaPods!
We're super thankful that Emerge is stepping in to help us out with this. CocoaPods.org, Trunk, and all the other websites we maintain are a critical part of the CocoaPods ecosystem, and we're glad to have Emerge's support to keep them running.
Read on →
CocoaPods 1.11 raises the minimum Ruby version to 2.6 while adding support for Ruby 3.0. It also adds support for 'On Demand Resources' and contains numerous bug fixes and improvements!
Read on →
Part of the server-side validation for uploading a new CocoaPod to the central repository of Podspecs (trunk) could be exploited to execute arbitrary shell commands on the trunk server.
We were contacted via Max Justicz this morning who provided us with a great technical write-up and showed how to trigger it for ourselves. The exploit is a combination of un-sanitized user input getting through to a git call param which can be used to send remote payloads.
Being able to execute arbitrary shell commands on the server gave a possible attacker the ability to read the environment variables, which could be used to write to the CocoaPods/Specs repo and read the trunk database.
This means you will need to log in again to trunk again to deploy any new Podspecs. If you have automated deployment to CocoaPods working right now, this will break, and you will need to pod trunk register again and replace your COCOAPODS_TRUNK_TOKEN. We're sorry, I know that sucks, but it also guarantees that you are the only person with write access to your pods.
If you are not a pod author, you do not need to do anything.
Read on →
CocoaPods 1.10 drops support for Ruby 2.0, adds support for Ruby 2.7 and adds initial support for Xcode 12 as well as a revamped XCFramework integration process!
Read on →
CocoaPods 1.9 adds support for XCFrameworks, configuration-based dependencies for pod authors, code coverage in generated schemes, and other enhancements and bug fixes!
Read on →
CocoaPods 1.8 switches the CDN as the default spec repo source and comes with a few enhancements!
Read on →
CocoaPods 1.7.2 brings with it the final version of CDN support for the trunk specs repo.
Read on →