CocoaPods 1.0

I'm incredibly happy to say that, after an incredible four and a half years of development, we just released CocoaPods 1.0. It's been a long road to get here, but the journey has told the story of the larger Cocoa open source community -- from new versions of Xcode to new languages and platforms, CocoaPods has grown over the years to support a staggering number of developers.

Across all of our various projects, we've accumulated ~20,000 commits by ~400 developers, closing ~22,000 issues -- it’s truly been a community effort to get here to ~19,000 pods and ~86,000 versions. With this release, we're committing to keep CocoaPods stable, and promising that it's ready to be used in production (see this entry in our FAQ we've been dying to delete for years).

Since adding stats a year ago, we got a real idea for the scale of CocoaPods’ impact. CocoaPods has been used to integrate ~285,000,000 pods into ~850,000 unique Xcode targets.


Let's get the changes in 1.0 out of the way first. The overarching principle we followed was to prepare CocoaPods, the tool, for the next five years - rather than introducing any individual feature. CocoaPods is a tool that many rely upon to get their work done, and we don't take that trust lightly -- we decided to make breaking changes in one fell swoop so we won't need to do so again for a long time.

The following are the highlights of the 1.0 release, but it’s been seven months since our last minor release, 0.39 (four and a half of those were the 1.0 beta period). As you might imagine, we’ve accrued quite a few changes, big and small, and you can find the summary of all 750 of those commits in the CHANGELOG. (The CHANGELOGs for the other projects under the CocoaPods organization likewise detail all of the other changes we’ve made during this time.)

Podfile DSL

By far the largest and most disruptive change, we've altered the way Podfiles work to make them better align with how we develop Cocoa applications. We recently put out a migration guide a few months ago detailing the majority of the changes -- we anticipate that most people will be able to migrate the most complicated of Podfiles in under ten minutes.

Here’s the tl;dr:

  • All targets have to be explicitly defined in the Podfile, and their names have to match up with the target name in Xcode.

  • Some command line options have been moved to Podfile installation options.

  • There’s a new target inheritance option that’s made to allow test targets to only inherit the search paths of an app target.

  • Abstract targets are now a thing. This makes sharing dependencies across platforms a lot less repetitive.

Improved Linter

One of the nice features CocoaPods provides is the ability to lint a pod, ensuring the Podspec is well-formed, and giving users confidence that the libraries they’re integrating can compile for the platforms declared in the Podspec. In 1.0, we go that final mile -- pods will be compiled and imported into an actual app to guarantee that no strange build or import errors come up.

Improved Sources Handling

As we posted about last week, we've made major improvements to how we handle updating sources to ensure that the Specs repo remains fast, usable and consistent. We’re happy this issue surfaced before 1.0 -- it gave us the push we needed to revisit some of the assumptions made before CocoaPods reached its current scale, and ought to provide a better user experience in the long run.

Automatic Deintegration

Changing the targets in your Podfile will no longer cause things to break when you go to build in Xcode. We’ve also made cocoapods-deintegrate a default plugin and pod install will now ensure that any target not being integrated with CocoaPods has all traces of CocoaPods removed.

CocoaPods Master Specs Repo Lockdown

When we announced trunk almost two years ago, we began the process of locking down the CocoaPods master specs repository. With CocoaPods 1.0 comes a policy change that completes that work -- we will no longer be accepting pull requests to the specs repo. In order to ensure pod owners still have full control, we’ve introduce the pod trunk deprecate and pod trunk delete commands. While we strongly advise against deleting podspecs from the specs repo, we’re putting that decision in the hands of pod owners.

The Past Five Years

CocoaPods began its life almost five years ago as a project started by Eloy Durán, taking inspiration from Bundler and RubyGems in lieu of any system provided by Apple.

The Cocoa ecosystem has been an interesting place to run a dependency manager, given the lack of control CocoaPods has on the underlying toolchain. It’s created some interesting problems, and the occasional nightmare. In the last year, Apple has moved into the space with Swift Package Manager, and we’re really optimistic about what it means for the community on the whole.

CocoaPods isn’t going anywhere any time soon -- we’ve poured our hearts into this project, and are so grateful for all the time and love it’s gotten from people on the team as well as all our users. There’s something thrilling about working on a project that has such large ambitions, and that people choose to believe in for their day-to-day work. As long as you all are using CocoaPods, we will continue to work hard to improve it. 1.0 is just the first step on that path.


As I mentioned earlier, CocoaPods owes an enormous amount to our community as a whole as CocoaPods has always been a reflection of the community. None of this would've been possible without everyone pitching in to make it happen.

However, there are a few people in particular I'd like to thank, because without their time CocoaPods would never have reached 1.0.

Eloy Durán

Eloy started CocoaPods, and is famously our 'final boss'. In addition to his vision for founding the project, Eloy has been brave enough to let others take the mantle and step into leadership. He established the team culture and is still often actively engaged, from helping with issues to building the foundations for the Mac app.

Fabio Pelosin

Fabio was a whirlwind for CocoaPods -- he came with no Ruby experience and over the course of a few years built a lot of the infrastructure that’s still in place today. Fabio still has the largest number of commits to CocoaPods projects, a title that won’t be wrested from him for a long time to come. He provided so much positive energy when handling thousands of GitHub issues in the early days.

Orta Therox

Orta, our Design Dictator, first joined the CocoaPods team by maintaining the pull requests on the Specs Repo, before we introduced Trunk. His first major contribution to the community was via CocoaDocs, which powered generating documentation for all pods. His work since then has been around the public-facing web infrastructure, the Mac App, community management, and design.

Florian Hanke

Florian is the only developer in this list that has never made a Cocoa app. He joined the team five years ago after meeting Eloy in Japan and has been working on the search engine for CocoaPods ever since. He was fundamental in creating Trunk, and helped out a lot with all of the CocoaPods web infrastructure simply because he enjoyed being with the group.

Kyle Fuller

Kyle helped set up important processes within CocoaPods, in addition to serving as release manager for almost a year. By helping us split the core of CocoaPods into plugins, and working on tooling necessary to manage micro-projects via CI, RuboCop and Rakefiles, Kyle laid the foundation for CocoaPods’ internal project management.

Marius Rackwitz

Marius gave himself one of the hardest jobs as a starter project - building Frameworks support for CocoaPods. This has been a multi-year project in reality, with edge-cases still popping up as the platforms evolve.

Boris Bügling

Boris has devoted considerable energy into ensuring CocoaPods supports the dizzying array of platforms, target types and Xcode project settings used in modern Cocoa apps. Additionally, he has been our consistent Triagemaster General in the fight to keep our issues under control.

Samuel Giddins

That’s me! I’ll do my best not to brag, but given I’m pushing the button (or typing a bunch of esoteric commands into a terminal) that actually does the release, I figured I’d add myself to the list. Since joining the CocoaPods Core team about two years ago, I’ve spent more hours than I can count implementing crazy new features and investigating the weirdest bugs. It’s been an absolute blast, and CocoaPods is as big a part of my life as anything else at this point. I look forward to the next 3000 commits on this little project of ours.


In addition to all of the people who have contributed their time and expertise to the project, we've been graciously sponsored in various ways over the past couple of years. First and foremost I’d like to thank Capital One, who have been sponsoring me since October, and thus supporting the majority of the 1.0-specific work that has been done since then. Additionally, I’d be remiss if we didn’t thank Artsy, Button, Discontinuity, Fingertips, Heroku, Realm, RubyMotion, Sauspiel, Segment, Slack, SoundCloud, Stripe, and Technology Astronauts for their loving sponsorship over the years. Without their support, the CocoaPods ecosystem simply could not exist in the form it does today.

Let's Celebrate

CocoaPods has been a huge part of my life over the past two years. I know that it's tempting to just say finally right now, but I think this is an opportunity for something more -- it’s a chance for us to celebrate, as a community. CocoaPods is more than just a tool -- it’s a community of wonderful iOS, Mac, watchOS, and tvOS developers. It's a team of dedicated contributors who selflessly give back by answering issues and making pull requests. CocoaPods has been my home for the past two years, and on the occasion of our 1.0 release, I think it's time we celebrate. The future is bright, and we've had a great journey getting here. Now let's grab some cake and enjoy the moment.

🎉 segiddins, Patch Master & Bundler of Joy