Carthage vs Cocoapods —A Build Time analysis use case

Guilherme Girotto
4 min readOct 1, 2018
Cocoapods vs Carthage

One of the most famous dilemmas that you will probably face yourself while developing iOS projects is which package manager should you use: Cocoapods or Carthage.

Of course, there is no right answer. Both approaches are possible and both of them have negative and positive points. But in this article, I want to talk about the experience that I had with both of them during Hercules development and why we’ve chosen to switch from Cocoapods to Carthage.

At the beginning of a project choosing Carthage or Cocoapods may be irrelevant when we talk about Build Time, because the number of used frameworks will probably be small. When your project starts to grow and more frameworks are added to it, Build Time becomes a concern, because a lot of development time starts being lost during long build times.

During Hercules development, we realized that we were losing around 15 minutes during build right after performing a clean command in the project and around 20 minutes to perform an Archive. At this point we were using 17 frameworks — some of them were quite big as Realm, Firebase, Facebook SDK and Google SDK — and Cocoapods as our package manager. Our Build Time was simply terrible and we had to do something about it. That’s when we’ve used an entire sprint to analyze and test hypotheses that would improve this lost time.

We started by analyzing our Build Time looking for which key points were taking too long to compile. Although our project is considerably big (+230 source files) we realized that the time taken to compile our source files wasn’t the problem. What happened during each Clean and Archive, was that a giant time was taken to compile all frameworks source files. That was happening because Cocoapods attach the frameworks source files as part of your project during each build. It means that every time you perform a Clean, it cleans all frameworks source files as well, even if you have never touched those files. How often do you modify external frameworks files? You will probably agree with me that almost never.

That’s when we decided to switch from Cocoapods to Carthage as our unique package manager.

Our reaction when I've decided to use Carthage

I'll start with one of the negative points of using Carthage. As soon as we started switching all frameworks we realized that some of them didn’t have Carthage support — Google SDK, Firebase frameworks, Facebook pop and Fabric Analytics. It means that we had to import all of this frameworks manually. Although it’s not a HUGE problem to do so, it's an extra work that we didn’t have with Cocoapods. Also, some frameworks manual install such as Facebook pop must be done by adding the framework PBX as a subproject of your main PBX, which has a similar behavior as adding it through Cocoapods, because the framework source files will be compiled on each build.

Shortly after importing all necessary frameworks manually, we’ve faced the second negative point of Carthage: the first carthage update. It took around 1 hour to compile all frameworks locally using no-use--binaries flag, which forced all frameworks to be compiled locally.

Although, after performing all these annoying changes, we started collecting the benefits of using Carthage: A 2 minutes Build Time after a Clean. It took around 20 seconds to compile the Facebook pop framework which had to be imported as a sub XCode project, and the rest of the time compiling our own source files.

That’s when we realized that switching from Cocoapods to Carthage was annoying in the beginning due to the manual work that Cocoapods made automatically to us, but it saved us an immense development time due to the Build Time decrease. Also, performing Archive will be as fast as compiling your code after a Clean, which means that if you perform manual releases frequently, Carthage will save your time again.

Summary

Cocoapods

Although Cocoapods is a more mature tool, has a higher variety of frameworks and is super easy to use, it can lead you to a lot of headaches performing clean builds and having to wait for all frameworks source files compile. Also, Cocoapods is a centralized solution, so be prepared to start losing control of your PBX/Workspace files, because from now, Cocoapods will start taking control and performing some changes at some points that you may not notice.

Carthage

The two negative points that we’ve noticed until now are a huge time that it takes to compile all frameworks if you decide to use local compiling and the necessity to import some frameworks manually. Although, the build time that we are saving while using Carthage make the initial negative points smaller.

Hybrid

Even I haven't mentioned earlier, you have the possibility to use a hybrid solution: Cocoapods and Carthage together. But I think that the consequences are intuitive: you will inherit the positive and negative points from both tools.

That’s the experience that I and my team had while using both Package Managers. I hope this text can help you in any way, so you can make a better choice of picking one. Thanks for reading and consider leaving a comment/feedback below :)

--

--