Time for action – using the barebone project as a template

We copied the barebone Sparrow template and used it as a template for our game. We renamed all project and scheme references.

We then needed to close Xcode, as CocoaPods will generate some files and we didn't want Xcode to interfere with the process.

In the next step, we had to define Podfile, which is the specification file for CocoaPods. This file tells CocoaPods which dependencies to fetch.

The specifications are written in Ruby, but they are easily understandable even to those who don't know the Ruby programming language.

The first statement sets the dependencies for the iOS platform. As mentioned earlier, CocoaPods can handle Mac OS and iOS dependencies even in the same project, so it makes sense for it to have a statement separating one from the other. As we are only targeting iOS, we don't need to worry about Mac OS dependencies and we leave that one out.

The second part of the Podfile in our example has all the dependencies we need in our project. As we only have one dependency—which is Sparrow—we only need to define that one.

A dependency is written in the following format:

pod 'name' 'version'

The repository with all dependencies and versions currently available can be found on GitHub at https://github.com/CocoaPods/Specs.

After our Podfile is written and saved, we need to get back to the terminal and let CocoaPods fetch our dependencies which is what pod install does. CocoaPods also generates a Pod folder which is where all dependencies are stored as well as an Xcode workspace.

From now on, instead of opening the project file, we need to open the workspace file as this is what CocoaPods updates and maintains.

If we were to open the project file and try to run the application, the application would fail to compile.

As the last step, we run our example. The indication that everything worked fine is when there are no errors while compiling the template and a red rectangle shows up on the screen.