In all of our apps, whether they are web-apps or iOS apps, we make extensive use of different frameworks. These help us to save time by abstracting out stuff that’s needed in a lot of different projects.
But these frameworks grow together with our projects, so copying these into several projects can become tedious and managing different versions would make things too complicated.
Ruby has Bundler to solve this problem. Just create a gemfile that lists every “gem” you use, Bundler will install these gems and keep track of the versions in the “Gemfile.lock”.
Now there is a similar system for Cocoa, called Cocoapods.
Cocoapods runs on macruby, so installing it using RVM is a breeze:
Then simply setup cocoapods like this:
And now we’re ready to start using Cocoapods.
Adding Cocoapods to a project
Using Cocoapods in a new project is quite similar to using Bundler in a rails project. We start by adding a Podfile which could look like this:
The platform can either be
Note that, just like with Bundler, you can specify a git repository, and even a commit or tag to reference your dependency. This makes it a lot easier to fix versions and avoid breaking the project when updating the dependencies.
The dependencies referencing a git repository must contain a “.podspec” file. When no repository is specified, Cocoapods looks for the podspec in it’s own spec-repository. There’s already a bunch of frameworks that are available, and more are sure to follow.
Now we can enable Cocoapods for our project by running
pod install for the first time.
This will clone the git repositories of the pods specified in a new “Pods” directory in your project root. Just like Bundler it will create a “Podfile.lock” which holds the references to the current version of the pods and its dependecies. Together with a new workspace we can use to open our project in XCode. There we will see that there are actually two projects added to the workspace.
One containing your regular project, and one containing the pods, this makes it easier to view the source code of these pods while working.
When building your project your pods will be built into “libPods.a” before building the project itself.
Now you’re good to go. When adding new pods or updating existing ones in your podfile just run
pod install again to update your “Podfile.lock” and adding or updating the Pods.
When multiple build configurations are needed, we also need to add these in the “Pods.xcodeproj”.
You should also set “Skip Install” to yes in your build target in order to create archives for different build types.
thanks Verbeeckx for figuring these last two out
Creating your own Cocoapods
To be able to add our own frameworks into our own projects easily, we had to add a “.podspec” to the repos. These podspecs look very similar to the gemspecs in Ruby.
In this podspec we set the source, where Cocoapods can find the repository to clone. We specify where the required classes can be found within the repository. We can also set several dependencies, specifying the tags that should be used.
Note that adding a dependency like this, it needs to be present in the spec repository of Cocoapods. When the correct tag or framework isn’t present in the repo yet, we can add it ourselves in the Podfile of the project we are using the framework in. In the case of Tin, we had to add “AFNetworking” separately in the Podfile because the highest available version from Cocoapods was 0.7.0.
I suspect Cocoapods will gain a lot in popularity in the future, because it makes adding dependencies to projects much easier. As it gains in popularity, more frameworks will become available.
I suggest you get over to the Cocoapods github and give it a try.
Sign up for our newsletter
Who’s got the mic?
Architecture & Design
Koen Van Der Auwera
Bob Van Landuyt
Nathan de Witte