This is the first part of a series of three blog posts on Cocoapods.
This post will mainly be an introduction to Cocoapods. These are the questions I’ll be answering: What is Cocoapods? How do you use Cocoapods? Why should you be using Cocoapods?
More information along with the installation guide can be found at:
Extensive documentation on everything regarding Cocoapods can be found on their github wiki
What is Cocoapods?
Simply put Cocoapods is a library dependency manager for Xcode projects.
Cocoapods works towards achieving the following goals:
- Make working with dependencies easy.
- Improve library discoverability and engagement by providing an ecosystem that facilitates this.
I will not cover the installation procedure in depth. A step by step guide can be found at the above mentioned url.
How do you use Cocoapods?
So you’re all setup, let’s dive in.
First of all we need a way to search for available libraries called “pods”.
You can search the public pod repository using the following terminal command:
“pod search <fill in you keyword>”
For example, let’s search for a networking library:
“pod search networking”
If all goes well you should see a listing of items that provide a match against the keyword “networking”. At the time of this writing, the only one listed is AFNetworking. This is the one we will be using.
Besides the name of the library, some additional information is provided: a short description, homepage of the library, source URL and the versions that are available through Cocoapods.
To specify which dependencies you would like to use in an Xcode project, a plain text file named “Podfile” needs to be created in the root of the Xcode project (where the project file resides) (https://github.com/CocoaPods/CocoaPods/wiki/A-Podfile)
After creating this file, open it using your favorite text editor. (I can highly recommend Sublime Text 2)
First line needs to specify which platform you are targeting. In our case this will be iOS. The first line should look like this:
Next add an empty line, this is just common practice and not required but provides a clean separation between platform specification and dependency declarations. Also note that the default iOS platform version is 4.3. So if you are targeting a higher version, you should specify it:
platform :ios, ’5.0′
Next we will specify our dependency, the AFNetworking library.
You can specify a dependency as simple as
This will take the latest version of the library and include that one in your project. If you want a specific version, you specify it behind the pod name.
pod ‘AFNetworking’, ‘~> 1.1.0′
I recommend specifying the version number. This way you’re always sure you are building against the same code base as you were when you started on you project.
The only thing left to do is run the following command in the directory where you created the podfile:
This will create a directory named “Pods” where all library code will reside.
The command also creates a Xcode workspace. From now on you always have to use the workspace, and not the original Xcode project you started out with. The workspace bundles two projects: your original project, and a Pods project. The pods project will create a compiled version of all your dependencies and expose it to your original project as a static library. Your original project will get modified slightly for example to include the path of the library header files in your header files search path. (Want to learn a little more about header search paths: http://www.cocoanetics.com/2012/01/helping-xcode-find-library-headers/)
Because our project basically uses a static library which we included, we should indicate this as such in our import statements.
To import AFNetworking in one of your source files, you should use the angular bracket notation.
(This way autocomplete also kicks in, if you use quotes, you’re on your own)
Why should you be using Cocoapods?
An obvious advantage of using Cocoapods is the easy integration of dependencies in your project but what makes it all the more interesting is the fact that you get a very clean separation of project code and library code.
This will make you think twice about modifying library code.
If you do need to change a thing or two, the Objective-C language provides us with enough tools to extend or change existing behavior, for example by using categories.
Mobile development speeds up every day and maintaining the ever-growing code base of our apps will become a lot more challenging. Cocoapods definitely provides us with a step in the right direction.
Part two of this Cocoapods series will cover the creation of your own pod libraries.