Firebase vs. Parse – A comprehensive comparison for iOS development in 2020 – Part 1

Introduction

Parse and Firebase are platforms created to make the developer’s life easier, building the server-side of your application much faster, solid, and scalable.

Those two products hit the market a few years back and evolved since, always bringing new functionalities and keeping up with newer technologies.

The two take different approaches to how they do what they do. Also in how they support the iOS development specifically.

As an iOS developer myself, I decided to write a totally unbiased view of both platforms for the iOS world and see how they approach this market share specifically.

A little history

Firebase was firstly developed by Firebse Inc. as far as 2011. As promising as it was at the time, it got acquired by Google in 2014 and evolved fast after that.

It holds as much as 19 products including pretty much everything you might need to get your iOS app up and running and it is remarkably solid and consistent among those products.

Features include database, hosting, authentication, real-time database, cloud messaging among others.

Parse was also developed as back as 2011 but by Parse Inc.
It made such success that in that same year it raised over $5 million in venture capital funding.

Parse also have many tools to make the developer’s life easier and supports pretty much everything that Firebase has.
Some approaches are different to reach the same functionality, though.

In 2013 Parse Inc. was acquired by Facebook, which decided to shut it down and reallocate the developers inside Facebook itself, which brought some anger to the developer’s world.

The developers made pressure and Facebook decided to open source Parse so everyone already running their apps in Parse would be free to keep running that way.

Since then, the community embraced Parse and, with the power of the community, Parse got a lot of new features and is widely supported to this day.

Same objective. Distinct routes.

As part of Google, Firebase would obviously favor the Android world, which is from Google too.

While it supports iOS (and is widely used), some features are clearly more “Google friendly” than its competitors.

One example is the fact that only a Firebase account can actually send push notifications to Android devices.

While my personal opinion on that matter is that it is just evil, it is their way to tell you if you want to communicate with Android devices, they have to be in the middle.
So if you have an application that must run in iOS and Android, you will need a Firebase account for that purpose, even if you write it in Parse.

The panels of both platforms are very distinct and take distinct approaches on how to configure and operate your app.

Also, the technologies used are distinct. For the database, for instance, Firebase had the Realtime Database, which evolved into the new Firestore, which is a scalable database that keeps the data synchronized across client apps.

Parse does not support a real-time database (by definition) at this point, but it does provide Schemas, Aggregations, and the ability to have relational data (even with a non-relational database), which Firebase does not. Also, the real-time ability is achieved in Parse using Live Queries.

But isn’t Parse dead?

Nope. It is alive, very well maintained by the community, and evolving every day.

The Vendor Lock-in Conundrum

Parse is open-sourced and free. You can download it and run it by yourself at any time.
You can also open the source code and see how it does things and even change it if you want to.

Firebase is closed-source by Google. It means only Google knows how it works inside and once you develop your App using Firebase, only Google can run it.

While Google is a super-solid giant company and you can rely on it, it is also known for discontinuing products. Out of curiosity, you can check Google’s discontinued projects at Google Graveyard.

So, if you run Firebase, you are stuck to Google and hopefully, Firebase won’t show on that list in the future.

Enough Talking

Let’s start comparing both platforms.

This first post will focus on the dashboards for both platforms and how easy it is to integrate with an X-Code project for Swift.

At the end of each section, I’ll give a score based in my personal opinion, which we will weight at the end of this series.

The Dashboards

Creating your first App in Firebase is quite easy as it has a very intuitive dashboard.

First, you click the “Create a project” button:

Then you give it a name

Then you enable or disable Google Analytics

And finally, attach your Analytics account

And you are finally done with the creation

One little thing is that I got an error while creating this App for the first time, but retrying it worked fine:

Now let’s try the Parse creation process.

First we click the “Build new app” button

Give the App a name and choose a version of Parse to use (for compatibility)

And we are presented with the Dashboard, which presents a quick tutorial on how to operate the Dashboard

At the end of the tutorial, you’re good to go.

Verdict – Creating an App

Both platforms are quite easy to operate when creating apps. Just a few clicks and you are good to go. So let’s call that a draw.

Integrating the Framework

Both platforms offer multiple ways to integrate the framework to your X-Code project, so in order to be fair, I chose the same method for both: Cocoapods.

If you don’t use Cocoapods to integrate frameworks to X-Code projects, you should consider using it or something similar instead of manually integrating. That will ensure everything is in its place, all dependencies are fulfilled and updates are done the correct way.

Configuring Cocoapods consists of editing the Podfile and running the command

pod install

The process will run (Firebase on the left, Parse on the right) and deliver a file with the xcworkspace format, which will have everything you’ll need.

Verdict – Installing the Framework

The process is easy and straightforward for both frameworks when using the same delivery method, so let’s call that a draw again.

Conclusion

This is the first article of a series and our contenders just showed up for the race. It is understandable that at this point both are tied.

In the next chapter, we will start coding and I expect the differences to start showing.

Keep tuned!