External iOS Frameworks

July 30th, 2015

Integrating external frameworks save you time and effort. Other people have already thought about problems that you would need to solve otherwise. In the beginning of the iOS development years the best way of doing so was integrating a static library in your binary. It was hard to do it right. Apple introduced embedding dynamically linked frameworks in iOS 8 (instead of statically linked libraries), which makes it very easy. Just add a subproject and embed the framework target from that subproject into your own target. But how to manage the codebase from that external framework?

Nowadays there are a few possibilities to manage external frameworks in your codebase:

• Copy over the source code. Don’t do that, now you’re the only one who’s responsible for updating that code.
• CocoaPods
• Carthage
• Git submodules

I’ll go through the different solutions and compare them.

CocoaPods

In the iOS development scene there’s a trend to use CocoaPods, for obvious reasons. You can search their database of frameworks and pick the ones you want to integrate. List them in a pod file and install them by running ‘pod install’. That’s it, no hassle in searching for frameworks, integrating, etc.

Pros

• It makes it very easy to search external frameworks and integrate them
• Supports both static libraries and dynamic frameworks

Cons

• There’s a learning curve
• It litters your Xcode workspace
• It makes you dependent on their scripts. What happens when Apple makes changes?
• The centralized way of listing frameworks makes you dependent on their infrastructure
• Very easy to cause problems by forgetting to “pod install”

Carthage

Carthage is an alternative for CocoaPods. Instead of creating a separate workspace with frameworks, it places the external frameworks in a subdirectory in your project root. It resolves some CocoaPod cons as listed above. The Carthage readme lists the following pros and cons:

Pros

• Not dependent on a centralized point
• Does not litter your Xcode project

Cons

• Only supports dynamic frameworks, which is a problem for targets with a deployment target of iOS 7.0 and lower. However, this apps are phasing out.
• Discovering frameworks is a bit harder because of the decentralization. At least we need to use Google or GitHub instead of the CocoaPods website.

Git Submodules

What CocoaPods and Carthage are doing, is exposing code from an external repository to your local repository, each with their own solution. Git already created a solution for this: Git submodules. In fact, it’s nothing more than having other checked out repos in your own git repo. Your own repo has a pointer to a certain commit within the external repo. If you own the submodule, it’s very easy to make changes to it, commit and update the pointer within your own repository.

Pros

• Independent from Xcode or whatever remote location, it works for all kinds of projects
• Updating your own frameworks is very easy. Just commit, push and update the reference to the submodule.
• You have an overview of all your external framework and their status in your git client, next to all your code changes.
• It’s easy to have submodules inside submodules and update all submodules recursively

Cons

• Submodule inconsistencies may occur while collaborating. I’ve seen this a couple of times. Most of the times you can just update the submodule recursively. In the worst case, you need to reinitialize the submodule.

What to use?

In most situations, the decision in what solution you use is dependent on personal experiences. What I tried to do, is to look objectively at the different approaches of integrating external frameworks in an Xcode project. My personal choice would be to use submodules above CocoaPods and Carthage, as this looks like the most robust and safe solution.