CocoaPods

CocoaPods is the preferred dependency management solution for all iOS, iPadOS, macOS, tvOS, and watchOS development, as well as all development in Swift and Objective-C at Vokal. It leverages a Ruby program to integrate third party code into your project. Furthermore, CocoaPods uses a plain-text file known as a Podfile in order to manage what dependencies and which versions of those dependencies are used in your project. For more information, here is a link to a CocoaPods Getting Started Guide

Vokal Guidelines

Vokal's Private Podspec Repo

As a reminder, your Podfile should have a line like

source 'https://github.com/CocoaPods/Specs.git'

If you are planning to use anything in Vokal's private podspec repo, you should add it as a source above the master podspec repo, so that you have

source 'https://github.com/vokal/PrivatePodspecRepo-iOS.git'
source 'https://github.com/CocoaPods/Specs.git'

at the top of your Podfile.

Note that for Libraries pointing at a public Vokal fork, you must make sure to point the Pod at our GitHub repo by using the :git parameter. Note that you can't specify a version when using the :git parameter, but you can point the Pod at a particular tag:

pod 'SFHFKeychainUtils-ARC', :git => 'https://github.com/vokal/SFHFKeychainUtils.git', :tag => '2.3.1'

Always Commit Your Pods!

One note on how we use CocoaPods a little differently from their traditional methodology here at Vokal: We always commit the contents of all Pods to a project repo.

This has several benefits for a team with many members like ours:

  1. Any new member of the team can pull a version of the project that will build and run at any time, even if they do not have the CocoaPods Ruby gem installed.
  2. Prevents version conflicts when one person has updated their pods but another hasn't.
  3. If the original Pod is removed by its author for some reason, we still have access to the code.
  4. We can ensure that our build server is always pointed at the exact code the team is using to build the project.

NOTE: Do NOT commit any changes you make yourself to any of the files in a CocoaPod to the main repo - these will get overwritten the next time someone runs pod install or pod update.

Updating Pods

Whenever you run pod install or pod update, make sure that you commit any changes that CocoaPods has pulled in, and make sure that you fix any errors introduced by those changes.

Remember: The goal of our setup is to always keep the project in a buildable state.

Caching credentials

Because CocoaPods uses HTTPS to access GitHub, it won't make use of your SSH key in order to access the private repositories used for our internal private podspecs. This means you'll be prompted for your username and password each time you pod install or update. GitHub has instructions to enable credential caching so that your creds will be stored (securely in the Keychain, for Mac users) so that you aren't prompted every time.

Creating a CocoaPod

Use Your Loaf created an excellent guide to creating a CocoaPod, complete with information about how to construct your podspec. For now, that should be considered the best guide to creating a podspec.

When creating a new private library, make sure that you create a podspec file and add it to our private podspec repo so that other members of the team can use your repo without having to rewrite the podspec themselves. Instructions on adding the podspec to our private podspec repo are here.

When creating a new public library, have a Senior engineer register it for Trunk so that updates can easily be pushed out. If you push the pod to Trunk yourself, please add the senior engineers as owners. In addition, make sure to ask the Senior engineer approving your updates to tag the release appropriately and push the podspec update up to the CocoaPods Trunk.

Further reading: