I love dependency files. Whenever I go through a new repository for the first time, I always take a look at it’s dependencies first. They’re revealing about the code and the author in so many interesting ways:
- What kind of stuff does the author think is worthy of rolling himself, versus bringing something in?
- What difficult problems does the app need help solving?
Unfortunately, for most launched/active apps and services, it’s hard to actually see these files (for totally obvious and valid reasons.). I feel like this leads to a tribal knowledge situation with package discovery: how are you supposed to learn about killer dependencies without getting to look under the hood?
I’ve been fairly cavalier with my cocktail app, Barback, to the extent that previous major versions have been posted on GitHub. The newest version of Barback isn’t open source (largely because the code is bad), but I wanted to give a dive into the dependencies I pulled in, in hopes that y’all might find it interesting.
So, first, here’s the Podfile for Barback 4. It’s pretty small!
target 'Barback' do # Comment the next line if you're not using Swift and don't want to use dynamic frameworks use_frameworks! # Pods for Barback pod 'Alamofire' pod 'AlamofireObjectMapper' pod 'Armchair', :git => 'https://github.com/UrbanApps/Armchair.git', :branch => 'swift3' pod 'Crashlytics' pod 'DZNEmptyDataSet' pod 'Fabric' pod 'Onboard' pod 'Popover' pod 'Reveal-SDK', '~> 5', :configurations => ['Debug'] pod 'Stencil', :git => 'https://github.com/kylef/Stencil.git' pod 'SwiftLint' pod 'SwiftHEXColors' pod 'SwiftyUserDefaults' pod 'TSMarkdownParser' target 'BarbackTests' do inherit! :search_paths # Pods for testing end target 'BarbackUITests' do inherit! :search_paths # Pods for testing end end
Now, line by line, each dependency and why I brought it in:
The definitive networking framework for Swift.
A marriage between Alamofire and the lovely serialization framework ObjectMapper. It lets me do stuff like this (snippet): my only qualm is that I wish it didn’t necessitate that all attributes be optional, but it’s still worth the price.
Bog-standard review nagging framework. It looks like I’ll get to remove this relatively soon in favor of iOS’s first-party replacement.
Handling of error reporting and basic analytics. The interface isn’t perfect and I wish there was an API, but the price is right and I have found no reason to switch.
Super simple empty state displays. Nothing fancy, but it saved me like an hour of implementation work.
Basically a wrapper around UIPageController that allows for onboarding tutorials. I’ve customized it for Barback to the point where using it doesn’t even really make that much sense, but it does it’s job capably even if you have to get pretty gross with hacking its’ views. (Gif).
Facebook-style popover views (gif). Simple concept, strong implementation.
Used to hook into Reveal, a terrific view debugging tool.
Provides Jinja-esque HTML templating; I use this to create the HTML for printing recipes and ingredients.
It’s a listing tool. I go back and forth on it, as I’m not a huge fan of a lot of the default rules and would prefer to wait to see a style guide emerge that I really dig, but it’s better than nothing.
Hexes to UIColors. I think there are like a dozen variations on this exact same idea but this was the first one in Google, and it does exactly what I want it to do.
Syntactical sugar around NSUserDefaults. Barback doesn’t store any server-side user information and uses NSUserDefaults for pretty much everything (including a lightweight cache layer), so this makes all of that interfacing much cleaner.
Information for recipes and ingredients are stored in markdown, and this parses them out to an NSAttributedString so they can be styled (rather than a lot of other approaches which involve UIWebViews. Ick.). I’m not thrilled with this solution – the parser seems to ignore block quotes, for instance – but it gets the job done for the time being.