Mobile Backend-as-a-Service or MBaaS was born to allow mobile developers who were short on time and wanted to build solutions by taking advantage of the latest features in a mobile device as well as manage complex service commands. The early leader in this nascent space was Parse. Parse set the groundwork for all MBaaS companies, providing us with cost-effective and easy-to-use tools for MBaaS. Earlier this year the service shut down. But the momentum of Parse opened up a path for other services to compete in the same space. The three emerging leaders in this space are Google’s Firebase, Apple’s CloudKit, and Kinvey.
With Parse shutting down, the developers who were counting on it for back-end services were left hanging. When they turned around asking for better alternatives to Parse the answers they got were in the vein of “You should’ve built your own back-end services and infrastructure” or “It’s time to get comfortable with AWS.” Perhaps this time around we should think more carefully about the cost of taking shortcuts. But the thing is, most independent app developers and small startups do not have the luxury of maintaining a dedicated back-end. Some are early in their lifecycle. They need to quickly develop and test to get to product-market fit before investing in their own infrastructure and services. They need Mobile Backend-as-a-Service (MBaaS).
For enterprises, MBaaS provides a selection of solutions which enable the rapid development of sophisticated mobile solutions. You see, a Backend is more than just a data store. Today there is no need for a company to scale cloud databases, host push notification server, or track app analytics on their own.
CloudKit is a decent Backend-as-a-Service, even though it’s a tad immature. Its claim to fame is its seamless integration with the Apple development ecosystem. To make CloudKit an indispensable and robust tool for developers, Apple still has to put in some more work. Today, CloudKit is essentially a data store with some basic iCloud identity authentication support and an API in front of it. The pricing model it offers adjusts free limits based on the number of active users of your app. CloudKit is excellent if data persistence is your key priority. The built-in notifications can be useful for social and other content-sharing applications. CloudKit will send your app notification, once your app subscribes to the changes on certain objects, and when those records are modified.
With its ease of use comes certain caveats. No functionality exists for implementing server-side logic. Another drawback is users are required to be signed into iCloud when saving any data. Most modern apps today use backends in much more sophisticated ways than the features CloudKit provides. Many applications require more flexible and sophisticated user management capabilities to manage identity, a comprehensive set of engagement features like SMS, push, email, etc., the ability to access data stores and files stores and a platform to run custom app logic which ties everything together. Flaws are present in the design of CloudKit, too. For instance, Apple asks developers to run app-specific logic on the client. This is an incorrect way to architect an app. This method can be a resource drain on the device itself while forcing developers to update the app whenever they need to make improvements to this logic. Another limitation is, CloudKit only supports iOS apps. But most apps live across multiple endpoints and need to be used on other mobile platforms as well as on web browsers. Webhooks, which was recently introduced may allow you to cobble together a cross-platform solution, but CloudKit is designed keeping iOS, Mac, and Web apps in mind. That said, we’re excited to see the direction in which Apple takes CloudKit.
On the other hand, CloudKit is an asset for developers building simple apps. Think shared lists, location-based review apps, Twitter clones, etc. But applications with a little more complicated logic need more than just some light authentication and a data store. They require access to data, identity, and business logic from any source, be it on the platform provider or elsewhere in the cloud, especially for enterprises, on existing on-premise systems of record. Overall, this seems to be the weakest service in this list, but, as with Firebase, Apple’s CloudKit is a lot easier to integrate into iOS apps.
Kinvey has the broadest selection of MBaaS services, in many ways. The code on the site enables rapid development for iOS, Android, HTML5, and Xamarin. Its core services include the database, push notifications, authentication and location services. There are many additional code snippet libraries. Many others can be brought into play, too. Check out the list for Android. Kinvey does offer a free tier for individuals or startups with fewer than 25 employees. But, for the rest, it is incredibly pricey at $24k per app, per year at the first tier. Due to the multitude of services they offer, Kinvey’s documentation is not as simplified as Parse’s, which is designed to get developers up and running quickly.
Kinvey is very user-friendly, but their pricing, support, and services are not ideal for small businesses. But since Kinvey is more focused on the Enterprise sector, I suppose it’s okay.
Firebase is one of the more popular replacements for Parse, with good reason. You can start saving data in no time, and their SDK is simple to use. Authentication with Google, Facebook, Github, Twitter, or email is a breeze with Firebase, especially since no additional backend is necessary. Dedicated Parse users will enjoy anonymous users, which was a Parse favorite. Additionally, offline storage is similar to Parse. Firebase could also serve as a replacement to Core Data. This will save you hours of development time. The real-time database is perfect for something like a chat app, or any other use case where data transmission is time sensitive. Push Notifications happen to be easy to setup and send through the dashboard. It is possible to subscribe users to pre-determined topics, create custom segments, or even send notifications to individual devices. Firebase Analytics is quite robust, too. It features not only custom events, but also high-level data along with demographics. You can get a complete picture of your user base by merely adding Firebase analytics. Additional features like storage, hosting, and remote configuration are a part of Firebase’s offerings. As you can see, Firebase offers us a full set of features. Combined with its ease of use, it sits right at the top of our list as our best Parse replacement.
Firebase, the BaaS most similar to Parse, backed by a big company with an excellent reputation in the field of big data, works cross-platform and is feature rich. Additionally, the Firebase service is free initially, with the pricing steadily increasing as you scale. Also, Firebase is a lot more popular, and as a result, there are a lot more tutorials available for it than for the lesser known BaaS providers. This makes one of the easier options for a developer to get up to speed on. But the JSON tree data architecture is a bit different than traditional data architecture and will take some getting used to. Also, some developers dislike Firebase’s API, and it doesn’t come with built-in support for push notifications. Firebase tends to be pretty hard to use, sure it’s powerful, but it’s also very complicated. Firebase will have a longer learning curve, but it has more to offer. If you are more inclined towards Google services and you are an individual or a startup, consider Firebase.
Which MBaaS should you go for?
Don’t let your backend end up a bottleneck for your app. Also, take into account the risk of longevity, or rather the lack of it. If the service isn’t around in a few years, you’ll have to find another alternative and migrate. So consider how easy it is to migrate data away from a particular platform. Another thing is, some of these options require more server and DevOps knowledge than others, which could add a significant amount of complexity. And looking at costs upfront is necessary, but also take a look at how those costs will scale as your application scales. End of the day use technology you are already comfortable with or one you are looking forward to learning.
Thoroughly evaluate the services mentioned to see what fits your needs best, but our team is increasingly leaning towards Google’s Firebase. The most impressive thing about it is, the service is designed from the ground up to be cross-platform, unlike Apple’s CloudKit which is mainly iOS-centric. The push services and free analytics are a bonus with Firebase. However, for more extensive databases, you might want to consider mixing up your environment with Amazon Web Services. In a nutshell, if you want a straightforward way to store data and are iOS only, CloudKit is probably the best option. If you were comfortable with Parse, and want something similar, Firebase is the best bet. If you can afford it, consider Kinvey.