CocoaPods Blog

2016 CocoaPods State of the Union

Apple have their annual WWDC keynote and Developer State of the Union. We have ours. We're planning a great opening event to WWDC week: The CocoaPods Alt State of the Union. You should join us, and hear about what's happened in CocoaPods in the past year, and what's to come in the next. This year's is going to be extra-special, as we'll all get to celebrate the release of CocoaPods 1.0 together πŸŽ‰

Read on β†’

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!