If you’re an iOS developer, you’ve probably used CocoaPods to manage 3rd-party libraries in a project by now. Personally, I don’t think I’ve worked on a single (serious) project that hasn’t used CocoaPods to manage dependencies. It’s a super great tool that not only makes the usage and management of external libraries in your project easy, but also makes the discovery of worthwhile libraries easy as well. This is due to the fact that the spec files for each pod are publicly available on CocoaPods’ central repository, where it’s easy to search for what you want.
That’s all well and good if you’re working on apps that just use open-source libraries, and don’t have the need to share private code between your different apps. Once you start needing to share code across projects, however, it’s a good idea to start making your own pods, and to make them available through your own private repository. Cocoapods already has a good guide on how to do that, which you should check out if you’re not familiar with setting one up yourself.
Working with private spec repos is pretty easy, and it doesn’t take too long to get the hang of it. The process is pretty straight-forward: put together a .podspec, test it with the pod spec lint command, push it up to the repo, and use that pod in your projects.
However, if you’re like me, you probably don’t quite trust the pod spec lint command to catch everything, and you want to make super double sure that what you’re pushing up truly works. After all, just because something passes tests doesn’t mean it actually works. Pushing broken code sucks, especially if others are depending on what you’re working on. On top of that, I personally just don’t like pushing up many commits that clutter up a repo that just contain small fixes that could have been avoided with a bit more work.
To make sure that I’m only pushing code that’ll truly work, I like to set up very basic test projects to see how the pod behaves when it’s pulled down with pod install. Before I had a better understanding of how CocoaPods worked, the only way I knew how to test this was by pushing updates to a centralized repo, rolling tag or commit IDs in the podspec, and pulling down the changes. This would result in a bunch of commit history with comments like “fixing…”, “bumping…”, “rolling…”, and other pretty useless messages.
Setting up a locally-hosted Cocoapods specs repo on my machine helps me do this much more quickly, and without needing to push potentially non-working code to a central repo for testing. With a locally-hosted spec repo, I can make quick iterations to a podspec file and test it out without polluting a repo used by others with half-working or unnessecary commits.
It’s actually a fairly simple process to set one up, once you know how. There are basically just two steps to actually creating the repo itself. First, you create a bare git repository in an empty directory.
$ mkdir LocalSpecs
$ cd LocalSpecs
$ git init --bare
This will turn the directory into a git repository1. Next up, we tell our pod tool about our new repository, and where to find it.
$ pod repo add LocalSpecs file://localhost/path/to/repo
or if you’re still in the repo, just
$ pod repo add LocalSpecs file://localhost$(pwd)
Now you’ve got your own local podspec repo. Easy!
Okay so now you’ve got your own locally hosted spec repo up and running, and there are a couple of things to keep in mind when using it.
The first thing to keep in mind is that the pod tool won’t automatically pull from your private spec repos, and that any time you’re using a private repo you need to call it out. This means that you’ll need to include a source line in your Podfiles like:
source "file://localhost/path/to/repo"
If you get to the point where you’re making private pods that have dependencies on other private pods you’ve created, you’re going to need to make sure that anything that uses those private pods knows where to look as well. So if you’re going to be running pod spec lint on a podspec that depends on another podspec only available in your private repo, you’ll need to do something like the following:
pod spec lint TestPod --sources=file://localhost/path/to/repo,https://github.com/CocoaPods/Specs.git
That will direct pod to fetch from your private repo when testing your spec file.
Setting up a private spec repo is a pretty simple task, and taking the few minutes to set it up will give you the ability to iterate on a .podspec quickly, and without making a mess of your widely-available spec repo, whether it be the public trunk repo, or your own private repo. Ultimately, this is only really all that useful for testing or local development; hosting a private CocoaPods spec repo on your own machine is unlikely to be very easy to use with a team, or even just on your own. That being said, I’ve already found myself in situations where a locally-hosted spec repo was very useful as a private staging ground where I could debug and test out different configurations on my .podspec files.
The use of the init command here may be different form how you’ve used git before. The --bare flag means that we’re turning the current directory into the actual repository directory (.git by default), and not using it as a project directory (more info on that here if you’re interested). The actual files from our git-controlled project aren’t actually going to be stored here, but rather in another directory. We’re going to leave that up to the pod tool to determine. ↩