As an iOS developer you have probably used third-party libraries or custom controls in your iOS project. At first, it seems easy, just drop in some files, link a library and you are done. You don’t feel the pain until you have to go back and upgrade your project either for a new version of iOS or the library. Multiply this with several projects, each with several third party libraries and you are dealing with a mess that sucks more time than you ever needed.

Now not only is there a solution to this problem but there are two solutions to choose from.

CocoaPods

CocoaPods has been around for quite some time and garnered a lot of community support. Basically, you create a Podfile that lists all your project dependencies in one text file. You then run a command line tool to install the dependencies which looks for a Pod, a spec file containing information about each library, based on the Pod it fetches the source code and adds the dependency to your Xcode workspace in a separate project.

VendorKit

VendorKit is fairly new and takes a slightly different approach. Once again you create a text file with all your project dependencies and then run a command line tool. Here’s where the difference becomes obvious: Cocoapods use standardized Podfiles that contain the names of libraries and probably version numbers which, in turn, fetches a Pod detailing information about each library. With VendorKit, you specify the library name, where it’s located, and if it has other dependencies. There is no standardization. There is a vendor spec file, but it’s only required if the library has other third-party dependencies. Other than that, it delivers on its promise, helping you manage your dependencies.

Both approaches have their own merit and and it all depends on your requirements and workflow.