CocoaPods Blog

CocoaPods App 1.0

After about a year of work, with the release of CocoaPods 1.0, the corresponding Mac App is also ready for public usage.

This is no big reveal, we've been advertising it's existence on our websites for a while. I've already talked a little bit about the tech behind the Mac App, so this post is the one that makes you say your team "we should use this instead of the gem".

So let me put my best hat on, and try to pursuade you that using the CocoaPods Mac App is a great idea.

Read on →

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.

Read on →

CocoaPods Socks available for the next four weeks.

TL;DR: We’re doing crowd-funded socks for charity, using Knitout. With all profit going to charity: water.

CocoaPods was started in 2011. We are a community run project, with no large-scale corporate backing. We're often asked if we'd do something like t-shirts or hoodies.

We don't want to use CocoaPods' popularity to make money. So, we are putting all profits into a charity. Want to know more? Go see

CocoaPods 1.0 Migration Guide

Major 1.0 changes TL:DR

  • You now have to define targets. Previously there was an available implicit target.
  • A target has to represent an Xcode target.
  • When you want to represent a collection of pods that go to multiple targets, use an abstract_target then add targets inside that. Pod dependencies are inherited by nested targets.
  • Targets that want to know about the pods for a target but don't need linking (for example, Test targets) can define that they inherit pods via their search paths (inherit! :search_paths).
  • :exclusive => true and link_with have been removed in favour of the above.
  • xcodeproj is renamed project to make the DSL vocabulary consistent.
  • We've removed the ability to declare :head on a pod—you can either use the :podspec option or point directly to the upstream repo (via git, :svn, etc.).
  • You can now declare installation options inside the Podfile via install! (e.g. install! 'cocoapods', :deterministic_uuids => false, :integrate_targets => false).
  • We've removed all DSL attributes that were classed as deprecated.
  • pod trunk delete and pod trunk deprecate have been introduced.
  • pod search improvements (this is great because it searches all your private spec repos too).
  • pod lib lint and pod spec lint will verify that your pod can actually be imported.

Read on →


During Summer 2015, we had the delightful opportunity to contribute to CocoaPods as part of Rails Girls Summer of Code (RGSoC). We were generously hosted and coached by GitHub. How did two newbie developers begin to work on open source, you might ask?

Read on →

App 1.0

TLDR: CocoaPods now has a Mac App that provides a hosted Ruby experience, go check out the web page for it:

The rest of this post is about how all the pieces come together to make a CocoaPods app.

Read on →

Release Versions Only

The main CocoaPods website,, lets you search for all versions of a pod. That includes prerelease versions. As a result, when searching for a pod with a prerelease version, the latest prerelease version is shown in the result list.

This sounds good in principle, but the behaviour is at odds with how the pod command operates. The default there is to use the latest released pod version. As a result of this – as we noticed via our stats system – usage of prerelease versions is minimal, and showing the latest prerelease version on violates expectations as to what pod install will actually install.

Therefore, we will be switching to the pod command default also on, meaning in the results, we will show only released versions. We've prepared all systems for the switch and will flip it on December 31st 2015 to start into the new year with the brand new search engine behavior.

Happy New Year, pod friends!


CocoaPods is a dependency manager only in the sense that Apple is a cell phone manufacturer – it’s just one of their many projects.

-- Ash Furrow - Building Online Communities

Last year, around this time, I started an annual write-up for CocoaPods. A lot happens in a project with 10 relatively active developers, and a lot of very welcome drive-by contributors.

Read on →

Introducing: Creme de la Pods

TL;DR: You could always find out what was new with @CocoaPodsFeed and Now you can see new CocoaPods that have a QI score of over 70 on @CremeDeLaPods.

Keeping on top of the community's work is a challenge, with ~13,500 CocoaPods available and roughly 20 new pods every day. We work on CocoaPods to encourage contributions to OSS. A by-product of this is that if you follow the whole stream of new CocoaPods, it can get hard to distinguish between "my first library" and "an awesome paradigm swift."

I have taken a stab at solving this problem, by trying to select the best pods by their Quality Index. The first time we run documentation parsing for a Pod, if that Pod's QI is over 70 then CocoaDocs will send out a tweet on the @CremeDeLaPods twitter feed, with the exact same formatting as @CocoaPodsFeed.

Read on →