CocoaPods vs Carthage

carthage   cocoapods   iOS  

Update

As a follow up to this article, I wrote a more detailed opinion piece on why I prefer Carthage. Hopefully it answers some of the questions and criticisms in the comments.

Original article

Recently I joined a project which uses CocoaPods as it’s dependency manager. I’ve not used CocoaPods for a couple of years so I didn't have it installed and had to go through installing again with one of the developers guiding me.

Afterwards I decided to write this para-phrased comparison based on my experience, but writing as if a developer new to CocoaPods was joining the project. I then decided to add the same conversation, except this time from the point of view of joining a Carthage project.


CocoaPods conversation

We’re using Cocoapods to handle dependencies in this project. It makes everything easiest.

Cool - I’ve never used it before, what do I need.

First check out the project.

Ok, checked out.

Now open a command line in the project directory and use gem install cocoapods to install cocoapods.

It’s saying my Ruby is too old.

Ok. Update your ruby then.

How do I do that?

Use rvm install ruby-head

Hmm. Looks like rvm is old too.

Ok. Use Brew to update it.

Ok. let me check I understand you at this point. I need to update brew, to update rvm, to update ruby, to install cocoapods - right?

Yep. Thats right.

Ok I”ve updated brew … and rvm … and told it to set ruby-head as the default version using rvm use ruby-head —default.

Ok. So go back into the project directory and do a gem install cocoapods.

Ok. Oh wait, it’s telling me I actually need Ruby 2.1.3.

Yes, we have anchored the project at that ruby version so we are all using the same one. So just do a rvm install ruby-2.1.3, then get out of the direct and come back in to reactivate it.

Ok. Now the gem install is telling that it actually needs Ruby 2.2.2.

Oh. Something must have changed. Ok. install that version then and redo the gem install cocoapods.

Ok. It’s done. Now what?

Now type pod install to get the pods project fully created. It will take some time initially because CocoaPods uses a single central git repo of all the available dependencies and it has to download that first.

Hmm. Well that took some time. Now it’s telling me that some of the pods won’t compile.

Hmmm, thats odd. What version of cocoapods is installed?

Cocoapods version 1.0.1

No, we should be using 0.39

Well the gem installs 1.0.1.

Oh wait, did you use Bundler?

What’s Bundler?

It’s another Ruby app that we use to specify all the versions of the gems we install. It uses a Gemfile in the root of the project.

So… it’s another dependency manager?

Yes.

Hmm, why does the Gemfile specify an old version of cocoapods. Presuming that a version of 0.39 is considerably older than 1.0.1.

Um, well, we can probably update it. Bundler will take care of the rest.

Yeah, but I’d rather not bring in yet another dependency manager. I'd like to see how I go with manually using 1.0.1.

Ok. Let me go do some Podfile and project updates to make it work.

The Podfile is where you configure CocoaPods?

Yes thats right, but don't touch it without reading the CocoaPods Podfile documentation first. There's a lot of things you can do in there to configure the project and dependencies.

… Some time later and a few git pulls …

Ok, I’ve got the pod install to work. So I can open the project and start working on it right?

No, don’t open the project. Open the workspace CocoaPods creates. CocoaPods requires you to use workspaces because it creates additional projects for the dependencies and compiles them with your project.

Oh ok.

Plus it needs to add xccofig files to your main project, modify build phases, add additional settings and other stuff to support each projects requirements.

Hmm. So does it always build all the pods as part of the main project?

Yes and no. It will build the dependencies as part of your build, but once built, they are skipped by Xcode.

Hmmm, but if I clear the project's build directories or derived data paths, it’s going to have to rebuild everything again?

Yes.

Even if there is no change to the dependencies?

Yes. But CocoaPods is an awesome dependency manager.

Ummm, yeah, sure.

Install summary:

Duration:3+ hours from check out to able to work
Required installs:Brew, RVM, several Rubys, Cocoapods and Bundler.
Number of dependency manages involved:3
Complexity:High
Project impact:High

Carthage conversation

We’re using Carthage to handle dependencies in this project. It's a decentralised dependency manager that makes everything easier.

Cool - I’ve never used it before, what do I need.

First check out the project.

Ok, checked out.

Now install Carthage. You can download a DMG installer from the Carthage GitHub page.

Cool. Done.

Good, open a command line in the project directory and use carthage bootstrap to download and build the dependencies.

Ok. Done. Now what.

That’s it. Carthage builds the dependant frameworks and leaves them for you to include in your project in the same way you would include an Apple framework. it doesn’t require any changes to your project’s settings or build and we’ve already added the framework references to the project so there’s actually nothing more you have to do at the moment.

The only time you have to worry about it again is if you want to update the dependencies. Then you just update the Cartfile with the new dependency or version and run carthage update. The format is just a simple list of dependencies so it's easy to do.

Awesome. Thanks.

Install summary:

Duration:10 minutes from check out to able to work
Required installs:Carthage.
Number of dependency manages involved:1
Complexity:Low
Project impact:None.


Comments powered by Disqus