A preliminary study of Carthage: four advantages and four disadvantages

[[140844]]

Carthage is a package management tool for iOS/Mac development ecosystem . Unlike the popular CocoaPods, it is a decentralized solution. I have known about it for a while, but I have never played with it. Today, I learned a lot from integrating Carthage and creating a Carthage-compatible Framework myself, so I decided to write a text to record it.

First, let's briefly introduce CocoaPods, which is a popular iOS/Mac package management tool. The current latest version is 0.37.2, which already supports iOS Frameworks. It manages a total of 10,822 libraries (and growing), allowing developers to easily integrate a third-party library.

After using it for a while, I think CocoaPods has the following advantages:

• Easy to use, except for writing Podfile, almost everything else is done automatically;
• There are many software packages and mainstream support;
• Support iOS 8 Framework, and of course also support old static compilation;

However, as a solution with a central repository, CocoaPods also has obvious shortcomings:

• Each time the environment is updated, it needs to be connected to the central warehouse, which is time-consuming;
• It is relatively simple for developers to use, but it is relatively cumbersome to create a CocoaPods-compatible library (despite the command line);
• Every clean build will recompile all third-party libraries (seemed correct until I met Carthage...)

You already know one advantage of Carthage. Yes, if you use Carthage, all third-party library dependencies do not need to be recompiled unless they need to be updated. This greatly speeds up the time for normal compilation and archive. Each archive and clean compilation can save more than dozens of seconds, which is still very considerable. For this reason alone, Carthage is worth using.

So, what are the advantages of Carthage? As mentioned earlier, it is decentralized and has no central server, which means that every time you configure and update the environment, you will only update the specific library, and there will be no process of obtaining the index of the *** library from the central server, which saves a lot of time.

"Okay, okay, if there is a third advantage, I will be convinced and start using Carthage!"

The third advantage is: seamless integration with CocoaPods!

"What? Using two package management tools for one project, won't that cause problems?"

After my own experiments, I have successfully transformed my "Singularity" project into a configuration where Carthage + CocoaPods jointly manage dependencies. There is no conflict at all.

Because Carthage is not a fully automatic and full-featured third-party library configuration tool like CocoaPods, its design philosophy is to complete the trivial parts and give the main control to the developer. It will not generate a Workspace like CocoaPods, which means I can freely control how to put the Framework into my Project/Workspace, whether it is Required or Optional. When I found that Carthage is so flexible, I did not hesitate to give a small number of other Frameworks to Carthage for management under the current configuration of CocoaPods managing the main Framework. They coexist very harmoniously.

In fact, there is another main reason why I use Carthage, which is that it is so simple to create a third-party library and make it available to Carthage. I don't need to use a complex structure + declaration file model like CocoaPods. I only need to create a Project/Framework and set the Framework Scheme to Shared. In this way, the directory of my third-party library is very clean, without any files related to Carthage, but Carthage can find and use it. I like such a simple and pure technical solution.

The above is the fourth advantage of Carthage: projects with standard structures are naturally Carthage libraries.

After listing these four major Carthage advantages, let's talk about its shortcomings:

• The library is still not as rich as CocoaPods: Although many libraries can be used directly by Carthage without declaration and modification, there are still a large number of libraries that can be used by CocoaPods that are not supported. I believe that time will solve this problem;
• It only supports Framework, so it is iOS 8 Only. As time goes by, this will not be a problem;
• The tool is still not perfect: I found that it could not correctly discover libraries in a complex project (such as iOS, Mac demo + framework structure);
• Unable to locate source code in Xcode: If you want to jump to a third-party library to see the specific implementation while writing code, this is impossible. Carthage configuration only allows you to see the header file of a library;

I don’t know when these four disadvantages will be solved (I think the fourth one cannot be solved due to project configuration), but considering the four advantages mentioned above, the use of Carthage still saves me time and effort.