CocoaPods is a powerful tool when it comes to package management for iOS development. But this time let’s focus on another package management tool, Carthage. If CocoaPods is like an aircraft carrier, it’s solid and solid. So the Carthage is like a cruiser, mobile and quick to attack.

Carthage and CoaoaPods

CoaoaPods is a holistic solution where we specify the third-party libraries we need in our Podfile. CocoaPods will then download, integrate, and then modify or create the workspace file for our project.

Carthage, by contrast, is much lighter. It also has a description file called Cartfile, but Carthage doesn’t make any changes to our project structure, let alone create a workspace. It simply takes the third-party libraries configured in our description file, downloads them locally, and builds the framework file using XcodeBuild. We then integrate these libraries into the project ourselves. Carthage uses a non-invasive philosophy.

This is the way to think about non-invasive philosophy. I’m sure those of you who have used CocoaPods have experienced this experience, especially in the beginning, where we carefully configure the third-party libraries we need in our Podfile, type in the commands that CocoaPods tells you to do, Then wait for those third-party libraries to be integrated into the project. However, there are always a few times when things go wrong, such as after running the POD update command, everything seems to be going well and the workspace is successfully updated. But when we actually compiled the build project, something inexplicable went wrong, like this:

diff: /.. /Podfile.lock: No such file or directory diff: /Manifest.lock: No such file or directoryCopy the code

When we encounter this kind of problem, we can only go through a series of searches and then solve the problem. Originally, we used package management to integrate third-party libraries more conveniently and quickly. As a result, we wasted a lot of time dealing with these package management errors.

With Carthage, we don’t have to deal with these issues because Carthage doesn’t make any changes to the structure of our project, and these additional issues like CocoaPods don’t happen.

Carthage doesn’t have the same integration capabilities as CocoaPods, so as a developer, you have to manually associate the library with your project after Carthage has built it.

In addition to being non-intrusive, Carthage is also decentralized. Unlike CocoaPods, Carthage does not have a central server (cocoapods.org) to manage the meta information of each package. Instead, Carthage relies on the source address of each third-party library, such as Github. Such an edge, the advantage is that we are package management no longer rely on a central server, not by a central server information and the stability limit (especially in the problem of network access in our here), disadvantages, is that we want to find a third-party library, also does not have a central server to help us to index, but must be from the Internet to find.

Carthage and CocoaPods have their own strengths and weaknesses, and it’s up to you to choose between them.

Start using Carthage

Now that we’ve covered the basics of Carthage, let’s look at how to use Carthage for package management.

To start, you need to install the Carthage environment, which can be downloaded from its Github homepage at github.com/Carthage/Ca… :

The latest version of Carthage is 0.9.3. Download the Carthage. PKG package to install Carthage.

After installing the Cartfile, we can configure the Cartfile file in our project. You can create this file in the root directory of our project using any file editor you are familiar with:

In Cartfile, introduce a third-party library such as SwiftyJSON:

github "SwiftyJSON/SwiftyJSON"Copy the code

Then we save the file, go back to the command line, and type the command again:

$ carthage updateCopy the code

Carthage will then grab and use XcodeBuild to build third-party libraries:

*** XcodeBuild output can be found in. Checking out SwiftyJSON at "2.3.0" *** /var/folders/08/sys7159s6zjfd52t3p35qrbc0000gq/T/carthage-xcodebuild.yqDOKU.log *** Building scheme "SwiftyJSON OSX" in SwiftyJSON.xcworkspace *** Building scheme "SwiftyJSON iOS" in SwiftyJSON.xcworkspace *** Building scheme "SwiftyJSON watchOS" in SwiftyJSON.xcworkspaceCopy the code

After the update operation is complete, a Carthage directory is generated in the root directory of the project. This directory contains two more directories, Build and Checkout.

Build contains the built framework package:

Checkouts contains the source files of third-party library projects that are checked out:

Next, go back to the project Settings, go to the General TAB, and in the Linked Frameworks and Libraries at the bottom, add the framework file from Carthage/Build/iOS to the project:

Then in Build Phrases, click the + sign in the upper left corner to add a New Run Script Phrase:

Then type in the script area:

/usr/local/bin/carthage copy-frameworksCopy the code

Finally, add the SwiftyJSON path to the Input Files.

$(SRCROOT)/Carthage/Build/iOS/SwiftyJSON.frameworkCopy the code

The final result is as follows:

The purpose of adding the Run Script is to enable the runtime to find the dynamic library. This is not clearly stated in the official Carthage documentation. I have experimented with the fact that without the copy-frameworks script, the project would crash at startup because it could not find the dynamic library.

You can also add symbolic files generated by Carthage’s integrated third-party libraries to your project so that you can step into the code inside the third-party libraries while debugging.

Specific steps, or into the Build Phrases, and then in the upper right corner click New Copy Files Phrase, then the Carthage/Build/iOS directory SwiftyJSON. The framework. The dSYM drag in symbol file:

This way, once our project is running, we can step into SwiftyJSON code at a breakpoint.

One other thing to note about this symbol file is that if you are using Xcode higher than 7, you may have a compilation error after adding the symbol file. Then it could be caused by a build option.

In Build Settings, find the Strip Debug Symbol During Copy option and make sure it is set to NO.

And then you recompile it, and it usually passes. This compilation option specifies whether to process the symbol table while copying the symbol file. In the new version of Xcode this option is YES by default, so we need to set it to NO. This problem is also not mentioned in the official document. I encountered this problem when debugging. After searching for the reason, IT bothered me for quite a long time

Well, after a bit of work, we’ve successfully integrated the SwiftyJSON library into the project via Carthage.

The level is limited, and here is only a preliminary introduction to Carthage. I hope this article can be used to share with you. I believe that you have more intelligence and wisdom in front of the screen. You are also welcome to discuss your in-depth research experience together.

If you are still not satisfied with this article, there is more discussion about package management on our wechat public platform, follow the public account “swift-cafe” and send “Package Management” to check it out.

Carthage’s GitHub page: github.com/Carthage/Ca…

This site articles are original content, if you need to reprint, please indicate the source, thank you.

Newer

Find the beauty of accident – SwiftyJSON source | coffee time to study

Older

The magic of Currying