Dependencies are as old as the art of engineering itself. In terms of iOS and OS X development, they are often thought of in the form of Cocoapods or Carthage libraries, or really just any bit of code from elsewhere that we bring in and use in our app.
There's also implicit dependencies we work with such as Xcode itself, or the language we write in. Today we'll look at some of the questions involved with using dependencies and try to answer them. Let's begin.
First up: How do we know what bits to write ourselves, and what bits are good candidates for third-party solutions?
Typically, it's good practice to try to limit the number of dependencies in general. Rules always have exceptions, but the thinking goes "the less moving parts, the less that can break." A decent way of thinking, but surely we don't want to build a full computing unit from raw silicone every time we have an idea for a new feature, right?
As the always-great John Siracusa puts it:
"It's all about finding where to draw that line."
Another reasonable guideline might be to "use libraries or frameworks that are used by lots of other people."
This is great. We want code that's been used on the App Store, and on millions of customer's devices. Code in which most of the bugs have been discovered and squashed long ago.
Once we've decided to integrate a piece of third-party code, we have to think about how.
Any of these are fine choices, it's really depends on the use case. Cocoapods is great, but requires use of an .xcworkspace file, and clean builds will rebuild all pods from scratch. Carthage doesn't have those issues, but can sometimes be at odds with the latest Xcode/Swift compiler changes.
The bottom line is: Carefully consider each option, and make the best choices you can.