What’s the catch to using Open Source Software in my iOS app?

In a previous post, I covered the benefits of using Open Source Software (OSS), but as with everything else in life, there’s a trade-off you make when using software written outside of your company and your engineering team’s standards.

Before getting into the nitty-gritty, I would like to state that most experienced engineers know how to vet OSS, so I will not spend the time covering how that’s done, as it’s not conducive to this blog’s audience; non-technical business owners who want to build an app. However, what I will cover are the pitfalls and repercussions of using certain types of OSS projects at the onset of the development of your iOS app.

First, not all OSS is of the same quality. Just because one library/module, which is what we refer to a single piece of OSS, is available for your use for free, does not mean it is free of bugs. This means that every library/module that is brought into your application is essentially bringing in a potential list of other people’s bugs. Are you willing to take that risk? With certain projects, especially ones with large communities, the answer should be yes for two reasons; (1) those projects tend to be less bug-ridden, and (2) they save your engineers, and by extension, you, a lot of time/money rebuilding the wheel.

This leads into my second point, which will be more clearly delineated by a hypothetical situation in which an engineer chooses to use a library in your iOS app that was well maintained at one point in time, but due to one reason or another, it has now been abandoned by the original developer(s). We call this type of software, be it free or paid, Abandonware. Over time, such software becomes stale for a plethora of reasons (to be covered in a future blog post). What does this mean for your app? It means that at some point that library that was included in your app may stop working or may become buggy, as there’s a hypotehtical chance it may no longer be interoperable with the changes made to the iOS libraries that Apple provides with each new version of iOS, or to a third-party platform that your app leverages. There are three ways out of this situation; (1) your engineers, and by proxy, your company, becomes the new maintainers of this project, or (2) you remove this third-party code and build it yourself, from scratch, or (3) work around having to use this library. None of these situations are ideal, but unfortunately, there are times when these decisions must be made.

There are two real-life situations that I am reminded of when it comes to Abandonware in the iOS community. While I do not know the full story behind each situation, I do now how each ended.

  • In 2010, Facebook released the Three20 OSS library, which at that time, provided iPhone developers with a lot of useful user interface (UI) components. In 2013, they killed off the library, as Apple began supporting some of these features, and because it was no longer conducive for Facebook to maintain this library. No alternative was made available, so the community began maintaining them in separate, disparate libraries.
  • In 2013, Tumblr released the TMCache OSS library. At the time, it enabled an easier way of storing temporary data onto the hardrive space allocated by Apple to your app. In 2013, they killed it off. Thankfully, alternatives existed, and one particular alternative was PINCache, which was an improved clone of TMCache, that was back then, and to this day, maintained by Pinterest.

As you can see, both stories had a happy ending, but for a brief moment in time, these scenarios caused each developer who used either of the aforementioned libraries to freak-out, as it had the potential of adding a lot of extra, unplanned work to their plates. I would like to state that this is not always the case. As you can plainly see, both projects that I mentioned, and all the parties involved in the development and maintenance of this software revolve around established companies, which is why alternatives were quickly made available. This is not always the case with libraries maintained by single indivudals or smaller companies.

The last item I’d like to cover are software licenses. Each software license comes with a different list of what you can and cannot do with each piece of software. Most OSS uses one of following licenses; Apache, GPL, MIT, Mozilla. All of these licenses allow you to package and distribute software in your commercial product. There are other benefits and limitations to each of the aforementioned licenses, but for all intents-and-purposes for this blog’s audience, you can make money without having to pay the developer(s) and/or maintainer(s) of the OSS your products makes use of. For a human-friendly list of popular OSS licenses and their permissions, conditions, and limitations, check out https://choosealicense.com/licenses/.

In summary, OSS, and by extension, OSS developers and maintaers are a boon to the technology world, as they have enabled, and continue to enable software developers to create more products at a faster pace. However, for the sake of your product and your business, your engineers must exercise discretion when deciding to incorporate some of these time/money-saving libraries into your iOS app.

One easy trick to ensure your iOS developers are maintaining best practices and keeping your codebase readable for years to come

You’re an entrepreneur. You’re building your Minimum Viable Product (MVP). You’re probably bootstrapping it or doing it on the cheap so you can show the MVP to some investors to obtain some much needed financial solvency to prove out your concept. This means you’re probably going to hire multiple developers over the lifetime of your product, and at some point, one of your new hires will look at your existing product and tell you that it was “written poorly” or “needs to be rewritten from scratch. If you’re a first-time tech-entrpreneur, this will be a rude awakening for you. If you’re seasoned, you probably know the drill.

What if I told you there exists a solution out there that will guarantee that your code, at least the way it’s formatted and structured, is following best practices? Now, what if I told you that it’s free? You might think that I’m a snake-oil salesman, but I assure you that I’m not. What I’m referring to is known as Code Linting, and what a Code Linter does is check to make sure the codebase is following community-established best practices, defined by a style-guide, for writing and formatting your code.

In the iOS community, specifically the Swift Programing Language community, the best practices are defined in two specific style-guides:

These style guides are used to create the rules that power the linter. In the Swift community, we use SwiftLint, which is a free, open-source tool that is maintained by the very best that the Swift community has to offer.

The earlier you have your developers set a linter up in your project, the more readable your codebase will be, and the sooner your app will be following best practices, and potentially less prone to bugs. However, this doesn’t mean your app will be bug-free, or your future engineering hires wont want to rewrite your app, but it may lessen the probability of either happening early on in your venture.

Open Source Software: What is it? Why should you use it in your iOS app?

What if I told you that there are software engineers that spend much of their free time writing and maintaining software that they give away for free? You probably wouldn’t believe me, or you might even call me crazy, because you’ve most likely had a hard time hiring an engineer for your company for cold hard cash. Well, it’s true! These people, myself included, love solving problems so much that we spend our free time doing just that, and then to top it off, we give away the fruits of our labor to the community at no cost.

You might be wondering why we people in a highly-sought-after profession would participate in this endeavor? The answer is simple — we like solving problems, abstracting the solutions we discover, and sharing it with the community, so other developers won’t have to deal with these headaches. (Side-note: we get street-cred in our respective engineering community for solving the problem). The best part is that you, the entrepreneur with that great product idea, get to piggy-back on our solutions (for free!), which enables you and your engineers to build your app faster.

This endeavor we participate in is known as the Open Source Movement, and the creations that are put out into the world are known as Open Source Software. This software powers the web. Not only that, popular open source software projects tend to be of higher quality than most other software, as this type of software, by its very nature, is inspected, edited, augmented, tested, and vetted by the community that uses it.

This begs the question, why should you use it? Simple — many open source projects, at least the ones that are maintained and vetted by the community, tend to solve common engineering problems. Why reinvent the wheel? This allows your engineers to concentrate on building the specific, challenging, and proprietary solutions required for your product to be successful. However, there are some exceptions to the rule. Both Realm and Artsy, two companies composed of developers that are considered luminaries in the iOS community, build their main products out in the open. They can do that because their product isn’t their main income generator; it’s the platform that these software tools leverage that generate the income.

In a future post on this blog, we’ll cover the specifics of where you can find Open Source solutions specific to the iOS community.