TWPods: Our Internal CocoaPods Repository

TWPods: Our Internal CocoaPods Repository

June 12th, 2014

We're big fans of CocoaPods here at Touchwonders. Every single iOS project we started in the past year makes use of CocoaPods. Our enthusiasm, in part, stems from a lesser known feature of CocoaPods, which I will talk about in this post.

When you run pod install, the master CocoaPods repository is cloned from https://github.com/CocoaPods/CocoaPods into ~/.cocoapods/repos/master. This repository contains podspec files for all pods that you can find on http://cocoapods.org/. If you take a look in my ~/.cocoapods/repos folder, you'll find a second folder there, named twpods. This is our interal, private, CocoaPods repository. It's just like master, except that we host the repository on a private server and that the podspecs it contains often also point to a repository on a private server.

I'd like to discuss three ways we use our private CocoaPods repository in our day to day work.

Internal libraries

Over the past, almost three, years that we've been creating iOS apps, we've gathered a collection of best practices and re-usable components. CocoaPods really is the easiest way to include them in any project you like without giving up maintainability of the component.

When you want to make changes to a pod, you can do this from within the project that you're using it in. Just make sure to add it as a 'development pod' in the Podfile, like this:

`pod 'TSDebugHistogram', :path => '../../TSDebugHistogram'`

This instructs CocoaPods to read the podspec from the local path you provide. All source files and resources are added to the client project as hard links, meaning you can make changes to them from within the client project and commit them in the pod's repository.

When making changes to a pod, do realize that it could affect all projects that use it. This sounds trivial and it is, but working on internal pods made me realize it even more. It also makes me see the importance of strict dependency version defifinitions (e.g. pod 'TSPIDController', '1.0.1') as opposed to the fuzzy one (e.g. pod 'TSPIDController', '~> 1.0').

Internal forks of external libraries

We like to use open source libraries in our apps and CocoaPods has made this easier than ever. There are a lot of pods that perfectly fit our needs and help us develop better apps faster.

Sometimes, a public pod is 'close, but no cigar'. It's useful, but not exactly what we're looking for. The benefit of open source then is that you can just dive in and fix it yourself. Ideally, those changes are merged back in the main project, but for all other cases, an internal CocoaPods repository can help.

We have a few private forks of public pods that we publish in our private repository so our projects can use versions of those pods with our own changes. A versioning clash should be avoided, so we append -internal to the version number, e.g. pod 'EDSemver', '0.2.2-internal'.

It could also happen that a piece of open source software that we'd like to use has no podspec or has a podspec that is lagging behind the project's development. I'll say it again: private CocoaPods repository to the rescue! We have one of those as well.

Highstreet

This third case is a special case of the 'internal libraries' usage discussed above.

The past year, we've been working on Highstreet: a platform of e-commerce apps. With Highstreet, we can build an e-commerce app in a matter of days. Highstreet-powered apps share approximately 98% of code: the Highstreet Core. Consequently, approximately 98% of the bugs will also be in the core. It is essential to the success of our approach that bugs only need to be fixed once and that these fixes are automatically incorporated in the following updates of the Highstreet apps. As you've probably guessed by now, the Highstreet Core is an internal CocoaPod.

In many ways, Highstreet.podspec is just like any other pod. It is just a lot bigger than your average pod. It contains an app delegate, lots of view code, xibs, assets, localized files, references to other internal pods and a Core Data model definition. But in the end it's just like any other pod and we think that's great.

'CocoaPods Black on White' by the CocoaPods Dev Team is licensed under CC BY-NC 4.