UITableView Swipe Actions


One of the new but little discussed APIs in iOS 11 allows the addition of swipe actions on UITableView rows via the new UISwipeActionsConfiguration class and associated UITableViewDelegate methods. Adding swipe left or swipe right actions is now pretty simple, so lets just dive right in. To try out these new APIs, a very basic list view was created with some hard coded data. This app will allow the user to swipe right to make a row “read” or “unread” and swipe left to either “flag” a row, or “delete” the row from the list. The code for this post can be found here.


The UITableView delegate

The keys to adding swipe actions start with new UITableView delegate methods, defined as follows:

func tableView(UITableView,
              leadingSwipeActionsConfigurationForRowAt: IndexPath)
                                    -> UISwipeActionsConfiguration

func tableView(UITableView,
               trailingSwipeActionsConfigurationForRowAt: IndexPath)
                                    -> UISwipeActionsConfiguration

As you can see in the method signatures, these both return a UISwipeActionsConfiguration class. This class is initialized with an array of UIContextualAction classes. So let’s start at the bottom and work our way up.


The Details

For our sample app, we’ll create a struct called an Email. It looks like this:

struct Email {
    let subject: String
    let body: String
    var isNew: Bool
    var isFlagged: Bool

    static func mockData(numberOfItems count: Int) -> [Email] {
        var emails = [Email]()
        for idx in 1...count {
            let email = Email(subject: "Email \(idx)", body: "This is my body for email \(idx)", isNew: true, isFlagged: false)
        return emails

    mutating func toggleReadFlag() -> Bool {
        self.isNew = !self.isNew
        //normally make some call to toggle and return success/fail
        return true

    mutating func toggleFlaggedFlag() -> Bool {
        self.isFlagged = !self.isFlagged
        //normally make some call to toggle and return success/fail
        return true

We will use this class to load up the table view with data. This is accomplished using the typical UITableViewDataSource methods and can be seen within the ViewController class. The real area of interest is within the UITableViewDelegate. Here we introduce the 2 new methods mentioned above.


Setting up the UISwipeActionsConfiguration

Let’s take a deeper dive into the trailing actions method, since it will apply more than one possible swipe action.

func tableView(_ tableView: UITableView, trailingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration? {
        let deleteAction = self.contextualDeleteAction(forRowAtIndexPath: indexPath)
        let flagAction = self.contextualToggleFlagAction(forRowAtIndexPath: indexPath)
        let swipeConfig = UISwipeActionsConfiguration(actions: [deleteAction, flagAction])
        return swipeConfig

Here, we are using a helper method to instantiate each of the UIContextualAction classes we will need to build our swipe actions. Then we can instantiate a UISwipeActionsConfiguration using the UIContextualAction classes to populate the actions array. The UISwipeActionsConfiguration is then returned from the delegate method.

The important thing to note here, is that the order of the items in the action array determines the order of the actions displayed when the table view row is swiped. The easiest way to remember is that the first item displays furtherest out, and subsequent items display moving towards the cell. So if we are dealing with trailing actions, the first item in the array corresponds to the rightmost action (“Delete”), the second one will be one inside of that (“Flag”), and so on.


Handling Contextual Actions

Next, lets take a look at the UIContextualAction. This is where the work happens. The documentation found here. The initializer takes a UIContextualAction.Style, title, and UIContextualActionHandler block. The UIContextualActionHandler gives you access to the UIContextualAction, the view that displayed the action, and a completion handler that you pass a bool indicating whether or not the action was successful. An example can be found in the contextualToggleFlagAction method shown below:

func contextualToggleFlagAction(forRowAtIndexPath indexPath: IndexPath) -> UIContextualAction {
        // 1
        var email = data[indexPath.row]
        // 2
        let action = UIContextualAction(style: .normal,
                                        title: "Flag") { (contextAction: UIContextualAction, sourceView: UIView, completionHandler: (Bool) -> Void) in
            // 3
            if email.toggleFlaggedFlag() {
                // 4
                self.data[indexPath.row] = email
                self.tableView.reloadRows(at: [indexPath], with: .none)
                // 5
            } else {
                // 6
        // 7
        action.image = UIImage(named: "flag")
        action.backgroundColor = email.isFlagged ? UIColor.gray : UIColor.orange
        return action

In this method:

  1. We are simply retrieving the data element from our data array
  2. Instantiating the UIContextualAction class, providing a style, title and handler
  3. Mutating the object. Of course our email struct could have been a class to ease the mutation handling.
  4. Saving the mutated object back to our data and reloading the appropriate rows.
  5. Call the provided completion handler, indicating success.
  6. Had the update to the object failed, we can indicate that to the completion handler by passing false.
  7. Setting the image and color attributes on action. By specifying an image, the title in the initializer is not displayed. This certainly makes localization a bit more work, since the images would need to contain any text we wanted to display for an action, assuming we wanted both text and images.

One more thing of note is that on the UISwipeActionsConfiguration class, you can specify whether the first action in the collection should be performed with a full swipe. This defaults to true. Here is a video of the working app with both leading and trailing swipe actions.


Changing your iOS App Icon programatically

When iOS 10.3 was released, Apple opened up an API to allow developers to change the app icon for their app. Of course this doesn’t mean you can change it every second like the Clock app, or even every day like the Calendar app. What you can do is change the app icon when the app is running in the foreground, and it will notify the user with a pretty ugly system alert dialog that the icon is changing. This post will walk through the configuration and API calls to allow an app to change the app icon.

The first step is to obtain your app icon image assets. These must be .png files and you will need 2x and 3x resolutions. An important thing to consider is that you want all the proper icon sizes available so that when the icon changes it is consistent across settings, spotlight, notifications, etc.

Unfortunately, these cannot be placed in a xcassets file, however, they must be packaged in the main bundle. The source code for this post can be found here.

The next step is to configure the Info.plist file. Review the documentation for the plist file carefully. In the provided code, the plist file contains the CFBundleIcons dictionary configured as show below:

Screen Shot 2017-07-13 at 9.19.42 AM

In the CFBundleAlternateIcons dictionary, the key represents the string that will be used when making the API call to change the app icon.  You will see these used in the code samples later in this post.  The value is an array of CFBundleIconFiles.  In our case, its an array of one item, with the relative path to the filename (without extension and size modifier).  If you like to keep your files organized in both Xcode and the filesystem like me, you’ll want to store your icons in a sub folder within your project, so it’s important to specify the relative path, otherwise you’ll get a runtime error when trying to change icons.

Now on to the code.  The API docs can be found here: https://developer.apple.com/documentation/uikit/uiapplication/2806818-setalternateiconname.  The APIs are pretty basic.  Ideally you want to check if the app can change the app icon with something like the following:

if UIApplication.shared.supportsAlternateIcons {
    print("I can do it")

Then to change the icon, do something like this:

//note that the name corresponds to the key in the 
//  Info.plist CFBundleAlternateIcons dictionary
UIApplication.shared.setAlternateIconName("hockey") { (error: Error?) in
    guard let error = error else {
    print("switching icon to hockey encountered and error: \(error)")

Finally, to reset the icon back to the primary one by setting the name to nil:

UIApplication.shared.setAlternateIconName(nil) { (error: Error?) in
    guard let error = error else {
    print("switching icon to primary encountered and error: \(error)")

Simple as that. Check out the sample app and switch icons between your favorite Philadelphia sports teams 😃

Saving Blood Pressure Data to Apple’s HealthKit

While working on one of our demo mobile apps for the upcoming SXSW conference, I found the need to store blood pressure and heart rate data in HealthKit. Apple’s documentation is pretty solid and has some good examples on how to use the HealthKit framework. In this short post, I’ll walk through the code snippets required to request access to write data to HealthKit and then actually write the data.

The demo app I am working on interacts with a heart rate monitor via BLE (Bluetooth Low Energy) to capture the users blood pressure and heart rate. The mobile app can start and stop the blood pressure cuff, display measurement progress, and finally show the results captured by the blood pressure monitor. Rather than having the app store any of that data, I decided to use HealthKit to make this information available to the iOS Health App and any other apps on the device that have read access.

Requesting read/write access to HealthKit

Let’s get started with requesting access from the user to write data to HealthKit. In my app I created a class called HealthKitManager, since every app needs at least one manager class.

class HealthKitManager {

    fileprivate let healthKitStore = HKHealthStore()

    func authorizationRequestHealthKit(completion: @escaping (Bool, Error?) -> Void) {

        // 1
        if !HKHealthStore.isHealthDataAvailable() {
            let error = NSError(domain: "com.chariotsolutions.mobile", code: 999,
                                userInfo: [NSLocalizedDescriptionKey : "Healthkit not available on this device"])
            completion(false, error)
            print("HealthKit not available on this device")

        // 2
        let readTypes: Set<HKSampleType> = [HKSampleType.quantityType(forIdentifier: HKQuantityTypeIdentifier.bloodPressureDiastolic)!,
                                          HKSampleType.quantityType(forIdentifier: HKQuantityTypeIdentifier.bloodPressureSystolic)!,
                                          HKSampleType.quantityType(forIdentifier: HKQuantityTypeIdentifier.heartRate)!]

        let writeTypes: Set<HKSampleType> = [HKSampleType.quantityType(forIdentifier: HKQuantityTypeIdentifier.bloodPressureDiastolic)!,
                                            HKSampleType.quantityType(forIdentifier: HKQuantityTypeIdentifier.bloodPressureSystolic)!,
                                            HKSampleType.quantityType(forIdentifier: HKQuantityTypeIdentifier.heartRate)!]
        // 3
        healthKitStore.requestAuthorization(toShare: writeTypes, read: readTypes) { (success: Bool, error: Error?) in
            completion(success, error)

I created an authorizationRequestHealthKit method. This method takes a completion function to allow callers to handle success and failure of the authorization request.
Walking through the code above:

  1. First, we need to check if HealthKit is available on the device. If not, the calling code should inform the user appropriately.
  2. Even though I am not reading data in my demo app, I wanted to include the read types sample code. The thing to note here is that blood pressure data is considered correlated data, meaning multiple samples that make up a single data entry. But there is no permission for correlated data. You are asking the user to read and write specific data types, in this case diastolic blood pressure, systolic blood pressure, and heart rate.
  3. This step is where some of the magic happens. This is where we ask the user for the exact data elements we want to read and store in HealthKit. The requestAuthorization method doesn’t actually indicate whether the user is allowing access, but whether or not the request for authorization has succeeded. The nice thing here is that based of the read and write types requested, the OS will present a screen with all the relevant information and controls to allow the user to make their access decision. Also, the UI will only be presented if the user has not yet allowed access to the requested data, meaning the UI only gets presented when required 🙂

Important safety tips:

  • The requestAuthorization completion block is called on the background thread, so be aware if your blocks do any UI work.
  • You must add messages that indicate the reasons for requesting permissions from the user. This can be done in the info.plist for your app. Just add the keys NSHealthShareUsageDescription and NSHealthUpdateUsageDescription with the pertinent messages as the values.


The authorizationRequestHealthKit method can then be called from wherever you need to request access to the user’s HealthKit data.

Writing the sample data to HealthKit

The next step is to actually write the data. The APIs provided for this are pretty straightforward once you see it. I added the following method to my HealthKitManager class:

func saveBloodPressureMeasurement(systolic: Int, diastolic: Int, heartRate: Int, completion: @escaping (Bool, Error?) -&gt; Void) {

        // 1
        let startDate = Date()
        let endDate = startDate
        // 2
        let systolicType = HKQuantityType.quantityType(forIdentifier: .bloodPressureSystolic)!
        let systolicQuantity = HKQuantity(unit: HKUnit.millimeterOfMercury(), doubleValue: Double(systolic))
        let systolicSample = HKQuantitySample(type: systolicType, quantity: systolicQuantity, start: startDate, end: endDate)
        let diastolicType = HKQuantityType.quantityType(forIdentifier: .bloodPressureDiastolic)!
        let diastolicQuantity = HKQuantity(unit: HKUnit.millimeterOfMercury(), doubleValue: Double(diastolic))
        let diastolicSample = HKQuantitySample(type: diastolicType, quantity: diastolicQuantity, start: startDate, end: endDate)
        // 3
        let bpCorrelationType = HKCorrelationType.correlationType(forIdentifier: .bloodPressure)!
        let bpCorrelation = Set(arrayLiteral: systolicSample, diastolicSample)
        let bloodPressureSample = HKCorrelation(type: bpCorrelationType , start: startDate, end: endDate, objects: bpCorrelation)
        // 4
        let beatsCountUnit = HKUnit.count()
        let heartRateQuantity = HKQuantity(unit: beatsCountUnit.unitDivided(by: HKUnit.minute()), doubleValue: Double(heartRate))
        let heartRateType = HKQuantityType.quantityType(forIdentifier: .heartRate)!
        let heartRateSample = HKQuantitySample(type: heartRateType, quantity: heartRateQuantity, start: startDate, end: endDate)
        // 5
        healthKitStore.save([bloodPressureSample, heartRateSample]) { (success: Bool, error: Error?) in
            completion(success, error)

There are different type of data samples that can be written to HealthKit. Blood pressure and heart rate data is considered a quantity sample. It’s made up of a sample type, quantity, and the sample data which includes the point in time the data was taken.

Let’s breakdown the method:

  1. Since all this data is captured at one point in time, lets capture the current date as the start and end date of the sample.
  2. Here we are constructing the systolic and diastolic sample data. Both the type and quantity are used to define the sample.
  3. This is where we correlate the diastolic and systolic measurements into one sample.
  4. The heart rate sample is its own measurement. The thing of note here is that the unit of measure (beats per minute) is a combination of count divided by time.
  5. Here we save the blood pressure and heart rate measurements, with the typical completion block. An example of a failure would be if the user has not granted write access for these measurements, the completion block will get an errorAuthorizationDenied error.

That’s a quick walk through of how to write blood pressure and heart rate data to Apple’s HealthKit.

Please note that this post was also posted by me to
Chariot Solution’s blog

Using Node.js and Charles Proxy to Mock a Server API

While working on an iPhone project for a client, I came across a situation where I needed to test some error conditions returned from a server API which I have no control over.  I ended up using Charles Proxy to remote map the server API calls to a locally running Node.js server.  Of course the proper way to do this is to write functional tests and mock the networking classes to return the appropriate responses, but that is a blog post for another day.

In this post, I’ll walk through the steps to create a simple iPhone app that interacts with a public API, using Node and Charles to simulate an error response.  This post assumes some experience writing iOS code, but all the source code will be available at https://github.com/stevenpsmith/charles-node-blog.

Create an iOS App

For the iOS app, I’ll write a simple weather app that uses the OpenWeatherMap API.  We all know the world needs yet another weather app :).

Let’s start by creating a new single view project in Xcode.  In my iOS projects I almost always use CocoaPods for dependency management.  CocoaPods makes it easy to add/remove 3rd party libraries to your iOS project.  In this app, we’ll use AFNetworking to access the API, and I’ll add MBProgressHUD in case the response time is slow and the user needs to wait for UI updates. The following assumes that you already have CocoaPods installed.

After creating the Xcode project, quit Xcode (or close the project) and create a text file named “Podfile” at the root of the project.  The contents should include the following:

platform :ios, '7.0'

pod 'AFNetworking', '~&gt; 2.0.3'
pod 'MBProgressHUD', '~&gt; 0.8'

With that file in place, drop to a command line and execute pod install

That will create a workspace and configure the libraries. From this point forward, we use the workspace instead of the project. The final version of the application will look like this:


The code base can be found at https://github.com/stevenpsmith/charles-node-blog, but the key portion is the API call, which is below (without all the details)

[[CSMServerAPI sharedInstance] weatherForLongitude:-75.1914 
    successBlock:^(NSDictionary *weatherDict) {
        // code to map API response to UI elements here
    } failureBlock:^(NSError *error) {
        //access error message parts from response here
        NSString *msg = ...
        UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Houston - We have a Problem" 
        [alert show];

If everything is successful, the UI gets populated with the weather data. But, if there is a failure, we throw an alert up to the user containing the error messages (I know, alerts are not user friendly, but this is an example).

Mocking an error with Node

Now that we have the API calls in place, we need to set up our node server to fake an error response. Sticking with the theme of keeping things simple, I used the express framework for node. With node installed, I created a directory for my server app and added a ‘package.json’ file inside. The ‘package.json’ looks like the following:

  "name": "mock-api",
  "description": "for use with charles proxy to mock error conditions for OpenWeatherMap API",
  "version": "0.0.1",
  "dependencies": {
    "express": "~3.4.7"

Dropping to a command line and executing npm install will set up the node server with the express module. Now we create an ‘app.js’ file and add our mock API, as follows

var express = require('express');
var app = express();

var errorJson = {error:"API Error",error_msg:"You have encountered an error thanks to Charles and Node....have a nice day!"};

app.get('/weather', function(req, res) {
  	res.json(400, errorJson);

app.listen(process.env.PORT || 4730);

Since our call to the OpenWeatherMap API is a get request to the /weather URI, we simply handle that request route in our code and return the response we want, which is an error containing a JSON error message. To start the server, execute node app.js at the command line and the server will be listening on port 4730.

Configure Charles Proxy for Remote Mapping

If you code against server APIs and don’t use Charles Proxy, or something like it, you really should start. It is immensely valuable for troubleshooting API calls, and the more I use it, the more nice features I find. I’ve used it for bandwidth throttling, request/response inspection, breakpoints (to change requests or responses), and now URL mapping. In order to map the OpenWeatherMap API to our local node server, access the Map Remote settings via the Tools -> Map Remote... menu. Once there, add a new remote mapping, filling out the fields as shown below. The configuration was also exported and is available at https://github.com/stevenpsmith/charles-node-blog.


With that in place, enable remote mapping, run the iPhone app and get the following error:


If you used Charles to record your network requests, you can even see the mapping occurred in the request overview notes. That’s all there is too it. You can certainly do a lot more than just simulate errors with this set up. I’ve used it to simulate server application errors as well, where server returns an http 200, but the response includes some application specific errors. Timeouts can be tested as well using the connect-timeout module. There is an example in the source code for that too.

So this is one way to intercept your API calls and modify them for testing. This is certainly no replacement for good functional tests, but simply another thing to add to your developer toolbox.

Apple’s New App Store Submission Requirements

Apple recently announced that new apps and app updates must be built with Xcode 5 and optimized for iOS 7 starting February 1st, 2014.

What does this mean?

Well, even if your app was built and released on iOS 6 and currently looks fine running on iOS 7, your next app update will change all that.  Building with Xcode 5 will now result in the app using the iOS 7 widgets when running on an iOS 7 device.  Depending on how your app was built, this could dramatically impact its user interface.  The changeover has had various levels of impact with our clients.

What should you be doing?

Build and test the application using the latest Xcode and iOS SDK.  This means test it on devices too (both iOS 6 and 7 devices).  Even if things look OK in interface builder, once you run it on the simulator and devices, things will start to look different.

Things to look for (just a sample):

  • API changes, deprecations, etc.
  • Differing control sizes and layouts (segmented controls, switches, progress views, etc.)
  • Navigation bar size differences
  • Edge-to-edge content (table views, content sliding under nav bars, etc.)
  • Status bar colors and translucency
  • Buttons
  • Images and Icons

Be aware that there are numerous way to support both iOS 7 and previous iOS versions, whether it be through auto layout, offsets, or code.  The best advice is to start planning as soon as possible.

Using Custom File Types to import data into your iOS Apps

Disclaimer: This is a repost of my entry on the Chariot Solutions blog.


I recently came across a situation where I needed the ability to share data between users of the same iOS application. Unfortunately, these users can not share an iCloud account and there is no server side components to this application. It is a standalone app.  Services like DropBox were not really an option either, as the devices are owned by an enterprise and will not have any service like that deployed onto them.

One solution is importing data via custom file types. Files can be sent to a device numerous ways (e.g. email, drop box, etc.), but for this post we will assume email. iOS makes it very simple to define a custom file type that your app can handle. This way, when the device receives an email with that type as an attachment, the user can select our app, giving it access to the underlying file. This post will walk through creating a simple app to access the contents of a text file received via email.

Create the Project

Lets start by creating a new project in XCode. I created a single view iPad application and called it “CustomUTIHandler”. I always use ARC. You can choose to use storyboards or not, as the UI in this app will do nothing more than display the contents of our file. The resulting project for this post can be found at:https://github.com/stevenpsmith/CustomFileHandler.

Define the File Type

The next thing is to define a file type extension that our application will support. This is also known as a Uniform Type Identifier (UTI). For our purpose, we will use a filetype of ‘csm’ (for Chariot Solutions Mobile). The contents of this file will be some string. It could really be almost anything, but for simplicity we will use a string. For a list of Apple defined UTIs, look here: http://developer.apple.com/library/ios/#documentation/Miscellaneous/Reference/UTIRef/Articles/System-DeclaredUniformTypeIdentifiers.html#//apple_ref/doc/uid/TP40009259-SW1.

Once we know what our custom file type extension is, we can add support for it to the project by modifying the Info.plist file for the project. We are going to be the owner/exporter of the new file type, so we add the “Exported Type UTIs” key to the Info.plist file. The default definition that gets created looks like this:

Based on the bundle key definitions found here: https://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html, we can fill in the required values. Since our example only has one file type that it is defining and the underlying data is text, we can add the system defined identifier for text to the “Conforms to UITs” item:


Next we need to add the identifier for our custom UTI. Apple recommends using the reverse DNS format in order to ensure our new UTI is unique. I will be using the following:


Finally, we want to identify the file extension that our app will be handling. This is defined under the “Equivalent Types” node. Add a node under the equivalent types with a name of “public.filename-extension” and a value of “csm”. You can optionally add a “Description” element under the Item for the exported type. My Info.plist now looks like this:

Support our new File Type

In order for our app to be recognized by the OS as supporting the newly defined file type, we need to add a “Document types” declaration to our Info.plist file. Doing so gives us the following in our Info.plist file:

The possible keys for the CFBundleDocumentTypes property can be found here: http://developer.apple.com/library/ios/#documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/TP40009249-101685-TPXREF107. We can add anything for the “Document Type Name” value. The handler rank will affect the order that Launch Services uses to present apps that handle this file type. Since our app is really the owner of this file type, we will use that as the handler rank. Now we need to add the “Document Content Type UITs” that our app will handle. In this case, we are only handling one type (as defined in the export key above):


Just for fun, we will also give our file type an image icon (included in the project). The specs for the image are defined in the keys document referenced above (64×64 in this case). So our final Info.plist looks like the following:

Now all we have to do is create a text file with a “.csm” extension and email it to our device. Once there, long press the resulting icon and we should see our app listed as one of the “Open in” apps.

Once we select our app, it will launch and pass the file URL to this app delegate method:

- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
So, adding a simple NSLog statement to the method and we can display the contents of our text file:
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
   if (url){
      NSString *str = [NSString stringWithContentsOfURL:url encoding:NSUTF8StringEncoding error:nil];
      NSLog(@"The file contained: %@",str);
   return YES;

Important Safety Tip

The files that are being opened by the application are actually copied into a directory called “Inbox” within the apps Documents directory.  My file was called “This is a test.csm” (great name right, what am I a windows user?).  As shown in the image below, there are copies for each time I imported it on my device.

These files should be cleaned up as required by your app.


So by adding some configuration to our apps Info.plist file and implementing a delegate method, we can handle any uniform types within our app.  The source code for this project can be found at https://github.com/stevenpsmith/CustomFileHandler.  I added some code so that it will display the contents of the file on the screen….very exciting.

Added Bonus

Since we are declaring to launch services that our app handles “csm” files, drop your custom file type into drop box.  Assuming you have the drop box app on you device, find the document in the app and try to open it.  You should get “Unable to view file”.  But if you tap the icon in the upper right of the screen, you should get a list of apps that can open that file….including our app.

It’s like magic 🙂  You see those other apps listed because we defined our UTI as text type, and those apps will handle text documents.

Using Cocoapods to Manage Private Dependencies

This is a re-post of my original blog entry, which can be found at: http://blog.chariotsolutions.com/2012/07/using-cocoapods-to-manage-private.html


Cocoapods (http://cocoapods.org/) is a dependency management framework for XCode. It allows you to declaratively define project dependencies and have them included in the build of your project. It’s like Apache Maven or Ruby Gems for XCode. There are many tutorials on getting started with Cocoapods, so in this blog post I will present a simple case where we have a project that depends upon two internally developed projects or private libraries.
We will start by creating two projects, each with a simple UI screen and some 3rd party dependency. Each of these projects will contain a file known as a Podspec that defines what gets included when another project depends upon it. Next, we will create a third project that depends upon these internally developed libraries and see how everything gets tied together.
In my contrived example, I’ll create two projects, each with a dependency on AFNetworking (a nice network abstraction layer). AFNetworking is already available via the public cocoapods spec library. Cocoapods will be used to add this dependency. Each project will also use YQL to query a weather service (Yahoo versus Wunderground) and present the forecast for a given zip code. The master project, which I like to call the Weather Comparator, will pull in the Yahoo and Wunderground projects and use their code to present a comparison of the services.

The Private Libraries

We start by creating the first project, Yahoo Weather. Once we have Cocoapods installed on our system, we create an XCode project for our first framework. I started using the Empty iOS application template. Once the XCode project is created, exit XCode. Create a text file called “Podfile” at the root directory of the project. The contents of the Podfile looks like the following:

platform :ios, '5.1'

xcodeproj 'YahooWeather.xcodeproj'

pod 'AFNetworking'

The first line defines the platform and SDK version, the next line defines the name of the XCode project file, and subsequent lines define the dependencies for this project. Podfiles can be much more complex, but this post will keep things simple. Check out the Cocoapods site for more information. Once the Podfile is complete, drop to a terminal and execute pod install at the root of the project directory. You’ll see some messages about the dependencies being downloaded and configured and when the process is complete, there will be a message indicating NOT to use the YahooWeather.xcodeproj anymore, but use the YahooWeather.xcworkspace file now. This is a workspace that includes your project and the Pods project.

Under the Pods project, there is a Pods directory, which contains the libraries specified in the Podfile (AFNetworking in this case). Besides creating the workspace, Cocoapods configures your project to include a static library called libPods. This is the output of the Pods project build. Essentially it includes the compiled version of the pods for which you asked to be included in the project. We can now use the AFNetworking classes within our code. The source code for the YahooWeather project can be found on my github account: https://github.com/stevenpsmith/YahooWeatherService. The finished app can actually be run and looks like this (I know, gorgeous, right):

Following the same steps, we create a second project called WunderWeather. Much of the code is similar, except now we are using the Wunderground weather API. There are some other small changes, but for simplicity sake I reused much of the same code, just using different names for the classes (notice the class name prefix). Again, remember this is a contrived example, so reusing the code was merely for time efficiency. The source code for WunderWeather can be also be found on my github at https://github.com/stevenpsmith/WunderWeatherService. And for your viewing pleasure, here is what it looks like:

One important thing to note here, is that each of our frameworks uses a slightly different class prefix. This ensures that when both of these projects get used in a third project (the WeatherComparator), there are no name collisions. Wouldn’t namespaces be nice?
When we are done coding each of these projects, we can commit them to our “private” git repository. In this case I am using github public repositories, but these projects can reside anywhere that is accessible from the projects that will depend upon them. That could a private repo, file system, etc. Cocoapods also support SVN and Mercurial, but git is what all the cool kids are using, so that is what this example will use.

Creating the Podspec

The next step is to configure a podspec for each of our frameworks. The podspec defines the source files, resources, etc. that our libraries/frameworks expose for use by other projects. In our case, we need to expose all the classes in the API, Model, and ViewController directories within our projects. We also want to expose our XIB files. Those are resources which need to get compiled and added to our final “.app” file. In a similar way, resources might include images that will get added into the “.app” file during the final build process. To create a podspec, execute pod spec create projectname at the root of the project directory. In our case, it would be pod spec create YahooWeather or pod spec create WunderWeather
The file that gets created has comments and examples of all the properties that can be set. For our projects, the podpsec looks like this (with all the extraneous comments and unused attributes removed):

Pod::Spec.new do |s|
  s.name         = "YahooWeather"
  s.version      = "0.0.1"
  s.summary      = "Provides a Yahoo weather forecast, with basic UI, for a given zip code."
  s.homepage     = "https://github.com/stevenpsmith/YahooWeatherService"
  s.license      = 'MIT'
  s.author       = { "stevenpsmith" =&gt; "ssmith@chariotsolutions.com" }
  s.source       = { :git =&gt; "https://github.com/stevenpsmith/YahooWeatherService.git", :tag =&gt; 'v0.0.3' }
  s.platform     = :ios, '5.1'
  s.source_files = 'YahooWeather/API/*.{h,m}', 'YahooWeather/Model/*.{h,m}', 'YahooWeather/ViewController/*.{h,m}'
  s.resources = "YahooWeather/ViewController/*.{xib}"
  s.requires_arc = true
  s.dependency 'AFNetworking'

Notice the source property. This points to our “private” repo. You can also access local repositories (instead of server based repos) by using a URI like this: '/Users/steve/projects/foo', which points to the root directory of your version controlled code. Also note the use of the tag key (which could also be a :commit). If consumers of this library do not specify a tag or commit, this specifies the snapshot of the code that will be provided. Without specifying anything, the latest commit of the master branch will be used. The source_files and resources specify the assets within this project that will be provided to the consuming projects. The dependency property specifies any pods that this pods would depend upon (in our case, AFNetworking). This file needs to be committed to the repository, and if a tag or commit is specified, that must exist within the repo as well. It’s a good practice to validate the podspec by executing pod spec lint <podspec_name>
This will save a lot of grief with typos, incorrect source directories, etc. Once your podspec is clean, commit it to the repository and tag if needed. The podspec for WunderWeather looks eerily similar.

Using the private libraries

The next step is to use these libraries in a new project. This is the WeatherComparator project, and it’s source can be found at https://github.com/stevenpsmith/WeatherComparator. We get started like we did before, creating the project within XCode, then exiting and creating a Podfile that references the dependencies. Except this Podfile will look a little different, as shown below:

platform :ios, '5.1'

xcodeproj 'WeatherComparator.xcodeproj'

pod "YahooWeather", :git =&gt; 'https://github.com/stevenpsmith/YahooWeatherService.git', :tag =&gt; 'v0.0.3'
pod "WunderWeather", :git =&gt; 'https://github.com/stevenpsmith/WunderWeatherService.git', :tag =&gt; 'v0.0.2'

Here we are adding the :git key to the pod declaration. Again, this could be subversion, mercurial, and even a filesystem reference. Notice there are no dependencies on AFNetworking. Our new project doesn’t directly depend upon those, but since the pods do, it will get pulled into our new workspace as it did in the other projects. Execute pod install in a terminal at the root of the new project directory, open the workspace as we did before, and we are good to go. Here is a screen shot of our weather comparator:

If you take a look at the code in the WeatherComparator project, it is very simple. One interesting thing to look at is the Pods-resources.sh script located in the TargetsSupportFiles/Pods directory within the Pods project. Cocoapods generates this script file based on the contents of the podspec for the libraries. This script actually compiles the XIB files and adds them to the projects final build. As you can see, pods can use storyboards as well. This provides a nice way to create modules that include UIs and then combine them into applications.
Even though we used github public repositories, this post shows how to use Cocoapods to manage your project’s public and private dependencies. To try out the project, install Cocoapods, download the WeatherComparator project, execute pod install at the root, open the workspace, run the project, and see how different Yahoo and Wunderground weather forecasts can be. Pretty surprising actually :).