How To Pick The Right Swift Open Source Component

With so many options available, it’s not easy figuring out how to pick the right Swift open source component. There are literally thousands, if not hundreds of thousands, of open source projects written in Swift on the web. You can find anything from simple UI widgets, to entire frameworks to support functional reactive programming. With all these choices, how do you pick the right Swift open source component to use in your project? Initially, you first have to find a component that actually meets your needs from a functionality standpoint. But after that, and arguably just as important, that open source code base must meet a minimum set of requirements to be considered for use in a production application. Here are the proposed minimum requirements to pick the right Swift open source component:

  1. Composition over inheritance
  2. Date of most recent commit
  3. History of past commits
  4. Popularity among the community
  5. Dependency manager support
  6. License
  7. Tests
  8. Proper versioning
  9. Maintenance ownership
  10. README

While most of this article’s proposed items apply to any open source project on the web, the specific examples cited in this article will be focused on performing the evaluation within the context of GitHub.

Composition Over Inheritance

You must have heard of “protocol oriented programming” by now. Have you heard what Crusty had to say? (Or if you want a quick read, here’s a good one.) When looking to pick a Swift open source component, it’s very important to look for one that prefers composition over inheritance. It should be in the forefront of your mind when looking to pick a Swift open source component. Think though how you would use the component? Look at the example usage. Does the component require you to subclass something in order to use it? Does the component require you to override base implementations of a super class in order to customize behavior? If so, steer clear. This is a sign of an inheritance-based customization model. Instead, look for projects that provide behavior customization through protocol conformance. Look for Swift open source projects that require you to compose the component as a variable rather than subclass something. These are signs that the project has already made an effort to code in the Swift way, rather than hang on to techniques of the past.

Date of Most Recent Commit

This is an easy one to measure. Simply look at the date of the most recent commit in the project. There’s no hard and fast rule that says the most recent commit should be within X number of days, but it shouldn’t be so old that the current version(s) of Swift or Xcode aren’t supported. Additionally the date of the most recent commit is also a good quick representation of how active the project is under development. If the most recent commit is months old, yet there have been many recent Issues opened with no response from the author, that’s not a good sign.

swift open source component

History of Past Commits

Aside from the date of the most recent commit, it’s also a good idea to peak at the history of past commits. While the most recent commit could be a couple days ago, that could be the first commit in an entire year. That’s not good. It’s good to look for a steady stream of commits. A large number of commits can be a double edged sword as well. If you observe a large frequency of commits, that can also mean that the project has not matured to a stable state yet. And additionally, if not paired with a solid release versioning strategy where designated “releases” are indicated as such, a high frequency of commits can indicate instability of the current code base without a clear designation of when the last “stable” commit was.

Popularity Among The Community

A popular project is a sign of a healthy project. The more people using a project, the more likely it will be that the project will be up to date to begin with, and also stay that way. Github makes this easy. Two things I look for to evaluate popularity are: number of Stars, and number of different committers. These aren’t steadfast measures though. Many popular projects only have a single committer. Just things to peak at. It’s unlikely that a project has widespread community support if there are a small number of Stars and a single committer.

swift open source component

Dependency Manager Support

There are three popular iOS dependency managers available today, and each has a different level of maturity: CocoaPods, Carthage, and Swift Package Manager. If you haven’t used any of these, or are unfamiliar with what a “dependency manager” is, you should absolutely stop right now and go try one out. They will change your life, especially if you routinely use third party code in your iOS applications. When evaluating a Swift open source component, it’s always a good idea to check whether the project has already provided support for at least one of the dependency managers. This is a good indication that the project is mature, and also has at least a minimal release versioning strategy. Those familiar with the tools above will know to look for a Podfile, a Cartfile or a Package.swift file. If the project doesn’t have this it’s not the end of the world, you can be the first to take action with the author to attempt to move the project in that direction. Use the author’s willingness or responsiveness as a followup indicator of whether you want to build close ties with the project.


If there was one personal choice amongst this whole list, this is it. Everyone needs to choose for themselves which open source license is appropriate. The only unacceptable red flag to steer away from in a Swift project on the web is to have NO license.


It wouldn’t be the Clean Swifter blog if there wasn’t a pitch for tests. Unfortunately, this is probably the least likely thing to find in open source projects. Don’t consider it a hard requirement, but consider it a HUGE bonus if the project has tests. It’s an even bigger bonus if the tests are connected to a public continuous integration build process (like Travis or BuddyBuild) with an indication of test results in the README.

Proper Versioning

This is another style of icing on the cake, and may have varied levels of important depending on the popularity and size of the project. Sometimes for smaller projects, the HEAD of the master branch can be consider the most recent “release.” That can get sticky though, because it may require you to manually keep track of which revision you are using in your project. It also leaves it open to interpretation the advertised stability of the current revision. A solid versioning strategy indicated by the Releases view in Github is a good indicator of a well maintained project.

Maintenance Ownership

Finally, the last thing to consider when getting in bed with a Swift open source project is how maintenance of the project is handled. How many different people have committed to the project? How many open Pull Requests are there for the project? Are the Pull Requests stale, or actively under collaboration? How many open Issues are there? Are they under active collaboration? Does the owner of the repository even allow others to collaborate? Your guaranteed to eventually find something you’d like to tweak when using a Swift open source component. Make sure that you have an idea from the start of how you would ultimately get that tweak in place when the time comes.


There’s something about well polished documentation that gives a shine of professionalism on Swift open source components. For GitHub projects, this is often in the form of the README. It’s front and center when looking at a project. If the README is thorough, up to date, typo-free, and well formatted, that goes a long way to indicate the quality of the underlying code. If the README is empty, wrong, or sparse, that’s a red flag. Also, look beyond the README into the other documentation. Take a peak a commit messages and documentation in the code itself. Is it well documented?

Wrap Up

Even with the most rigorous of evaluation of Swift open source components, you should make careful architectural decisions and design choices so that the coupling between your code and the third party code is loose and easy to be changed. This is a hard lesson to learn if you don’t do it. And don’t forget, the best thing about open source code is that you can see the actual source! Beyond anything else mentioned in this article, feel free to dive down into the source and make an evaluation of the code itself. After all, you can code too.

What’s missing from this article? Are there any other tricks that you use when picking a Swift open source component?

Happy cleaning.

PS – If you use CocoaPods, the team has done a lot to automate much of this list in the form of their Pod Quality Index. You can get a quick summary of the overall quality of any given CocoaPod. Here’s an example for Alamofire. Here’s the documentation on how it is calculated.

FBSnapshotTestCase Installation with Carthage

FBSnapshotTestCase installation failed with CocoaPods 1.0.0.rc.2 while in preparation for an upcoming presentation to Philadelphia CocoaHeads. I gave Carthage a try, and it worked! I wanted to write it up and share it with you. Now I know that switching to Carthage may not work for everyone just to use a test framework, but maybe there’s a hybrid solution that you could come up with?

What is FBSnapshotTestCase

FBSnapshotTestCase is a testing framework that was originally written at Facebook by Jonathan Dann with significant contributions from Todd Krabach. As a testing framework, it allows you to test the user interface of your iOS app by diff’ing screenshots. Yep, you heard me write, you literally take a source screenshot, mark it as “correct” and then all future runs of the test suite use this as the basis for determining if the test passes or not.

As my preferred channel, and as the README suggested, I wanted to install FBSnapshotTestCase with CocoaPods, but this issue prevented me from doing so in a Swift project. Instead, I tried using Carthage and was successful.

FBSnapshotTestCase Installation with Carthage

Step 1: Download Carthage

Carthage is an alternate dependency management framework, one that is more lightweight than CocoaPods (and doesn’t require Ruby! YEY). If you don’t have Carthage installed, download the latest .pkg file from here. I used 0.16.2 for this tutorial. FBSnapshotTestCase Installation was really easy with Carthage.

Step 2: Create a Cartfile

In the root of your project, create a new file called Cartfile. Add this to it:

github "facebook/ios-snapshot-test-case"

The Cartfile contains your dependencies for the project. While you can specify versions of your dependencies, I was content just picking the latest release, and thus didn’t specify a version.

Step 3: Install the Dependencies

Now that you have a Cartfile, the next thing to do is install the dependencies with Carthage. To do this, from a shell, run:

carthage update --platform iOS

You’ll see output like:

*** Fetching ios-snapshot-test-case
*** Checking out ios-snapshot-test-case at "2.1.0"
*** xcodebuild output can be found in /var/folders/mp/k1jy2r2d3gg9bzkz0v9y5jxm00024f/T/carthage-xcodebuild.GOHIjS.log
*** Building scheme "FBSnapshotTestCase iOS" in FBSnapshotTestCase.xcworkspace

A new Carthage/ directory will be created with your dependencies. Carthage is different from CocoaPods, in that, you now need to manually configure the libraries within your Xcode project.

Step 4: Add Dependencies to Your Project

Open a Finder window for the root folder of your project, and then navigate down the hierarchy to Carthage/Build/iOS. You should see the framework for FBSnapshotTestCase.

FBSnapshotTestCase Installation

Now, in Xcode, open the target settings for your test target, in my case it’s called SnapshotExampleTests, and then select the Build Phases tab, and then expand Link Binary With Libraries. Drag the framework in there:

FBSnapshotTestCase Installation

It will then look like:

FBSnapshotTestCase Installation

Step 5: Add a FBSnapshotTestCase

Create a new unit test (File -> New -> File):

FBSnapshotTestCase Installation

And specify it as a subclass of FBSnapshotTestCase

FBSnapshotTestCase Installation

At the top of the file, replace:

import XCTest


import FBSnapshotTestCase

At this point, you can try running your new FBSnapshotTestCase (Command-U). Everything should compile, but the test will fail.

Step 6: Copy-Frameworks

I’ll be honest, I’m not really sure why this final step is necessary, but without it, the tests would not pass. Carthage’s README indicates it’s necessary for an “App Store submission bug” but I’m not even archiving here, just running tests.

Do this (copied right from Carthage’s [README]):

On your application targets’ “Build Phases” settings tab, click the “+” icon and choose “New Run Script Phase”. Create a Run Script in which you specify your shell (ex: bin/sh), add the following contents to the script area below the shell:

/usr/local/bin/carthage copy-frameworks

and add the paths to the frameworks you want to use under “Input Files”, e.g.:


It should now look like this:

FBSnapshotTestCase Installation

Now, try to run your FBSnapshotTestCase again with Command-U. It should compile and pass your test!

Wrap Up

See, isn’t FBSnapshotTestCase installation easy? Now you’re free to go ahead and use FBSnapshotTestCase to your heart’s content. I plan to write another post that will help you through creating your first FBSnapshotTestCase. If you’re a long time CocoaPods user, I know this isn’t optimal, but hey, look at it this way, at least you have an opportunity to try out Carthage if you’ve never looked at it before.

I got a log of inspiration and ideas for installing FBSnapshotTestCase with Carthage from this article on <>.

Happy cleaning!