Dependency management is a key element of software engineering. For all but the most trivial applications, dependent libraries that extend your app’s abilities (and mitigate the need to “reinvent the wheel”) must be included, used, and kept up-to-date when they change.
In iOS, dependencies have typically been handled by dragging & dropping a compiled library (i.e. a .framework) into an Xcode project, or else dragging and dropping an entire subproject into the parent project. The latter option involves adding the subproject’s source (and/or header files) to a parent project; and neither of these options handle versioning and updates to the dependent subproject. If the subproject is updated by its owner, your code is out of date.
Git submodules solve some of these issues, but they do not provide the ability to update Xcode compiler or linker flags, or any other project elements that may require updating when a dependent project demands them. And the customary “delete the subproject and recreate all its settings” process is laborious and error-prone.
To solve these issues, the rapidly-growing standard for iOS (and Mac OS) is CocoaPods.
CocoaPods is Ruby-Based (But Don’t Let That Scare You)
CocoaPods is written as a RubyGem (itself a package management system for the Ruby programming language); fortunately, all versions of Mac OS X ship with Ruby, and aside from a one-line update to RubyGems, no significant knowledge of Ruby is required to use CocoaPods.
CocoaPods Allows “One-Line Installs”
After creating and maintaining a very simple settings file (known as a Podfile) where dependencies are declared, installing and updating CocoaPods libraries is as simple as typing a single entry from the command line:
Updates are just as easy:
Many iOS Projects Already Use CocoaPods
A “master repository” of projects using it can be found here.
CocoaPods Manages Compiler & Linker Settings
As an Objective-C platform going back decades to OS X, OpenStep and NextStep, there are many settings and options in iOS that are hard to remember and set correctly for every project and subproject. CocoaPods keeps this simple by automatically keeping track of these in each install and upgrade.
CocoaPods Manages “Dependencies of Dependencies” (and so on…)
iOS doesn’t have the same concept of namespaces as languages such as Java. Consequently, filename conflicts are a constant worry. This can be partly mitigated by naming all files distinctively (typically with a two letter prefix such as “AF” for the AFNetworking framework, “SZ” for the Socialize SDK, and so on)… but what if a project contains one version of a subproject, and another subproject contains its own, different version of that subproject? With CocoPods, all this is managed automatically to avoid conflicts.
CocoaPods Uses Xcode Workspaces
A Workspace in Xcode is basically a “project of projects” with a shared build directory. By automatically creating and maintaining the Workspace, CocoaPods integrates with standard iOS tools and workflow processes.
Coming Soon to a ShareThis iOS Project!
The Loopy iOS SDK, now in progress, will use CocoaPods for dependency and package management. This should greatly facilitate implementation of the SDK. A CocoaPods migration for the existing Socialize SDK is also being discussed.