How open sourcing magically improved our code
The story of ApeSuperHUD: Apegroups first open source project.
Why open source your code? You can reverse the question and ask: Why not? Shouldn’t the code we reuse internally hold a high enough quality to withstand public scrutiny?
There are many reasons why you should open source your code. The simplest being — Open sourced code is easy to find. Instead of having your reusable code in a repository somewhere where nobody is looking, you can simply Google it.
Another reason to open source your code is that you are more likely to make proper documentation, since your work will be official and out there for everybody to see.
The code itself is also likely to be of better quality. Firstly, you don’t want crappy code official with you name on it. Secondly, the more people using it, the more likely bugs will be found. Quoting Linus Torvalds:
Given enough eyeballs, all bugs are shallow.
Public code also gives us attention. We are proud of what we do and if our code can save some time for someone else, and put a nice glow around our name, that is worth a lot.
Why ApeSuperHUD?
One might wonder, why open source yet another ProgressHUD? There are lots of really good HUDs out there, what can this HUD possibly have that none of the others do? Good question. There are two main reasons: We wanted something written entirely in Swift and we wanted a specific three step function:
- HUD with a loading spinner.
- This spinner then updates itself when the loading is completed.
- After the loading is finished it displays a short message together with a icon.
You can say it is a combination between Android’s toast, and a traditional progress HUD.
During the development we added loads more nice features. Want to know more in detail about our awesome APESuperHUD and all it’s features? Check it out on github
How did we do it?
Create a Framework
We wanted to create a framework since it’s a great way to package the code together with necessary assets, like default icons. This great article by Jake Craige explains how you create your first Framework for iOS in Swift.
Dependency management
Since we wanted our framework to be easy for users to maintain, we added support dependency mangers. Dependency managers are great for keeping your third party libraries up-to-date, and in one place. There are two well known dependency managers for iOS today: Coacoapods and Carthage.
CocoaPods, beside downloading the code and handling the version, also links the library to your project. If you want to add CocoaPods support to your Framework you need to create and maintain a podspec file. This file needs to be pushed to CocoaPods trunk which requires a authentication.
Carthage lets the user link the library on their own. Carthage is only responsible for downloading the code and building the framework. We liked that Carthage gets the job done without taking over the responsibility of Xcode, and that it reduces the maintenance job by not having to update the podspec file for each release.
There is a third dependency manager out there, Swift Package Manager. Note that at this time the Package Manager has no support for iOS, watchOS, or AppleTV platforms.[1]
Result
APESuperHUD has now been “out there” for 9 months and the result exceeds our expectations. If you search for HUD on Cocoapods, APESuperHUD is the second result. If you select Swift only, APESuperHUD comes up as the first result. On GitHub it is the eighth most starred HUD written in Swift.
Result 14 oktober 2016:
CocoaPods:
- 4907 downloads
- 177 Apps
GitHub:
- 5 Pull requests
- 35 stars
- 5 forks
- 6 reported issues
Conclusion
Our thesis that open sourcing code makes it “magically” better seems to be correct. The community has helped us find bugs, and contributed with code improvements. We ourselves have used APESuperHUD in every new project we have made, and that says a lot!
We want to open source more. We see a lot of benefits and a lot of components that we have made and that we should share. Time is of course an issue when you are working in a customer project but this experience has given us a taste for more. We hope you will see a lot more fun stuff from us in the future.
Credits to Erik Fagerman who helped me write this article as well as initiating this open source project.
My name is Daniel Nilsson and I work as an iOS developer at Apegroup, a design and technology studio in Stockholm. If you want to know more about us, check out our website.
