Earlier this year, Parse announced it will retire its services in January of 2017. The announcement took many people by surprise, including me. When Facebook acquired Parse in 2013, many thought the future of the company looked bright. How wrong we were to think the acquisition was a guarantee for a long life.

At moments like this, we tend to look differently at the dependencies of our projects. The disappearing of Parse as a BaaS (Backend as a Service) provider leaves many companies out in the cold. Parse was one of the leading BaaS providers, powering tens of thousands of mobile and web applications. What options do the companies behind these applications have and what will it cost to migrate from Parse to another solution?

How wrong we were to think the acquisition was a guarantee for a long life.

Minimizing Dependencies

Whenever I create a software project, I try to keep the dependencies to a minimum. Because I use CocoaPods to manage the dependencies of my Cocoa projects, I have an accurate overview of the dependencies of each project. But is that really true? Are the dependencies of a software project limited to what libraries and frameworks it uses?

What has the announcement of Parse taught us? Nearly every modern software project has dependencies. We mostly think of dependencies as libraries and frameworks. But does it end there?

Grab a piece of paper and take a moment to list every dependency of a random project you work on. The App Store, for example, is a dependency for every iOS, tvOS, and watchOS application. Apple's iCloud services are another, often overlooked, dependency for modern Cocoa applications. The list goes on and on.

Dependencies aren't the enemy. But you need to carefully consider every dependency you add to a project.

It is impossible to create and distribute mobile applications without dependencies. In fact, the software industry is thriving for this exact reason. We create and build, using what is already out there. Dependencies aren't the enemy. But you need to carefully consider every dependency you add to a project.

Think Twice

As a developer or project manager, you need to consider the variables of the project. Do you use Twitter to authenticate users? Unless you are building a Twitter client, it may be a good idea to add other options, such as Facebook or Google.

The type of application is another important consideration. The explosion of third party Twitter clients significantly contributed to the platform's exponential growth. Everyone had a favorite Twitter client and it seemed for a moment that every developer was building one. Businesses were built on top of Twitter. Until, one day, Twitter felt it needed more control over the user experience, making the company decide to put limits on its API. A dependency suddenly turned into a liability.

What to Avoid

Code Dependencies

Third party libraries and frameworks are rarely a problem. Code is mostly easy to replace. You can write it yourself or find an alternative. Whenever you consider including third party code in a project, first answer the following questions:

  • Is the code open source?
  • Is the project under active development?
  • Can you build a solution in a day or two that solves the problem equally well?

These questions don't have a right or wrong answer. The goal is to make sure you understand the risk of including third party code in a project.

CocoaPods has made it very easy to manage dependencies in Cocoa projects. But that doesn't mean that every dependency is equal. CocoaPods recently added a quality index that indicates how healthy a project is. It is a good start, but you need to carefully consider which dependencies to include. You, the developer, makes that decision.

Other Dependencies

What other dependencies does your project have? Does your project rely on a backend? Do you host the backend? How long would it take to create a custom solution? Is your application functional without the backend? Assess the risk carefully before making a decision. A library is easy to replace, a backend is not.

A few years ago, Apple added iCloud support for Core Data. Developers were excited, looking forward to add iCloud support to their Core Data applications. Unfortunately, iCloud was not ready for prime time. As a result, developers were forced to cope with a problem they did not create and had no control over.

Limiting Risk

Few people saw the shutdown of Parse coming. It shows that seemingly reliable dependencies can turn into liabilities. The shutting down of Parse will cost companies tens of millions of dollars.

How can you limit these risks? Is building a custom solution the only option? Yes and no. If the project you work on needs a backend, then you will have to take a risk. The question is how big of a risk you are prepared to take. The goal should be to limit risks as much as possible.

I don't agree with this quote from Steve Streza, but there is a kernel of truth. You shouldn't blindly choose for a platform because it is popular. Consider the alternatives and, more importantly, consider the risks.

"Platforms like Parse/CloudKit should be thought of as massive technical debt that you WILL pay when you least expect it. Avoid at all costs." - Steve Streza

Backup Plan

This blog is hosted on WPEngine. If the company goes out of business, I will be up and running again in less than an hour. Even though I depend on WPEngine, I have plenty of alternatives to choose from and the cost of switching is negligible. What is the cost of switching from Parse to a custom backend on Heroku or AWS? It certainly isn't negligible.

What about CloudKit? Apple is heavily investing in its cloud services and it appears that the company is eating its own dog food. That is a good start, but it certainly isn't a guarantee. Apple owns the data. There is no exit strategy, which means you choose and stick with CloudKit. The CloudKit framework is great and I love working with it, but would I build an application that relies on CloudKit? I am not saying "no", but I am not saying "hell yeah" either.

There is no need to prepare for the worst scenario, but you should be aware of the risks you take. If you choose for a hosted solution, such as Parse, then consider the consequences before making a decision. Most projects will be fine when Parse shuts its doors next year, but a lot of time and money will be spent in the meantime.