CocoaPods Blog

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!. (i.e. 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 →

RGSoC

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: cocoapods.org/app.

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, cocoapods.org, 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 cocoapods.org violates expectations as to what pod install will actually install.

Therefore, we will be switching to the pod command default also on cocoapods.org, 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!

2015

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 feeds.cocoapods.org. 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 →

Capital One

I'm incredibly excited to announce that as of today my work on CocoaPods will be sponsored by Capital One.

What does this mean? It means that Capital One is stepping up to support continued development on CocoaPods and I will be able to focus on CocoaPods work while finishing university.

Read on →

Running SSH Commands via Rakefiles

TL;DR: CocoaDocs' commands which used to be executed via logging in are now done via rake commands.

CocoaDocs runs a lot of CocoaPods' infrastructure. It is the workhorse that allows us to provide rendered READMEs/CHANGELOGs, QIs and status updates.

I have been manually sshing in to the server to execute commands for a few years, and it's a bit of a chore. Over time though, I became used to this. As more people were starting to help out in maintaining CocoaDocs, it became obvious that it needed to change from being dark arcane knowledge to easy -discoverable- commands.

Read on →