Time for action – using the barebone project as a template
Follow these steps to use the barebone
project as a template:
Copy the
barebone
application from samples | barebone to a location of your choice.Open the Xcode project.
Click on the project name in the project navigator to make it editable.
Rename it to
PirateGame
.Open the Product menu from the top menu bar.
Select Scheme and Manage Schemes.
Rename the Scheme name from Barebone to
PirateGame
.Close Xcode.
Open any text editor.
Type in the following code:
platform :ios, '5.0' pod 'Sparrow-Framework', '2.0.1'
Save the file as
Podfile
in the recently copiedbarebone
folder on the same level as the Xcode project file. If you are using TextEdit (OS X default text editor), make sure to save the file in the plain format which can be done by changing Format to Make Plain Text in the menu. Also disable Smart Quotes by navigating to TextEdit | Preferences….Open a terminal.
Navigate to the copied
barebone
folder.Execute the
pod install
command in the terminal.Open
PirateGame.xcworkspace
with Xcode.Remove
Sparrow.xcodeproj
from the project by right-clicking on it and selecting Delete.Run the project in the iOS Simulator by hitting the play button. If there are any errors, try to change the Build Settings in the configuration by changing recursive to non-recursive in User Header Search Paths.
What just happened?
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.