CocoaPods > Git Submodules

I must take a moment to recant some comments I made over a year ago about CocoaPods in a post about OCMock.  The first time I came across CocoaPods I thought it was pretty awesome, but then reality set in.  I had problems getting my project configured.  It would sometimes crash with cryptic errors (and still does if you have syntax issues).  I had trouble getting it to work with our continuous integration system.  Then a developer I have much respect for told me to just use Git submodules–it does what CocoaPods tries to do the “right way” I was informed.

Fast forward a year and I have changed my tune.  Git submodules is a reasonable solution to the problem of integrating other projects–but that’s not the primary problem that CocoaPods solves.  The real power of CocoaPods is having a searchable repository of open source frameworks at your fingertips.  In addition, with Git submodules there is usually a messy bit of configuration to do in order to get the framework integrated–and if you decide you don’t want to use it, additionally messy work to remove it.

CocoaPods makes it simple to find and include thousands of open source frameworks into your project.  It does the heavy lifting of dealing with dependencies and integrating into your project.  It works with Xcode’s Bots and Jenkins.  You can even configure it to use a private repository which contains your own frameworks that are not to be distributed to the public.

What’s even cooler? It makes it drop-dead simple to create and distribute a framework for iOS or Mac.

The only thing you need to do is evaluate the quality of the code you’re using.  There’s a lot of stuff out there and not all of it is great.  Buyer beware (the linked article is about Ruby Gems, but applies to all open source code).