BaaS Selection for Fun and Profit

BaaS is getting a lot of attention these days., which we featured in our recent article on Mobile MVPs in Minutes has just been bought by Facebook and many people are starting to ask what is a BaaS, what can it do for me, why should I use one and which one should I use?

At ikuramedia we settled on Parse as our BaaS of choice around 12 months ago, which is an eternity in the technology world – so it seems an appropriate time to reevaluate our decision as well as assess how the Facebook investment will affect the ecosystem. We’ve identified three main competitors to Parse who have grown significantly since we last looked at them:

It’s also worth noting that appcelerator is also a contender in this area with their cloud services, and if you’re a cross-platform developer using Javascript it’s certainly worth a look. And finally, it would be worthwhile investigating some of the BaaS open source platforms such as BaasBox and Helios – but we’ll cover these in another post.

Finally, during our evaluation we came across both Kii and CloudMine – both of which are worth a look. Kii‘s principal advantage for us is their Asia base – which makes us more confident about serving local clients without worrying about the GFW… Their SDK looks remarkably similar to Parse – minus relational queries, and their pricing model appears to be identical to Parse.

CloudMine‘s information is somewhat more scarce on their website – I couldn’t find the pricing model without signing in, and they seem to focus on Agencies and Enterprises, but still worth a closer look when I get time.

Evaluation Criteria

Our focus is either on building great scalable experiences for our B2C clients, or rapidly rolling out flexible and feature-rich MVPs for our angel development startups. With this in mind, our criteria boil down to the following primary areas:

  1. Feature set – does it do what we need?
    1. Object Store – data drives the product, and having an online persistent store is super flexible for creating connected apps
    2. Queries – need to be able to retrieve the data that we’ve previously stored
    3. Object Relations – without a reliable method of connecting our data together we’re limited in the features and functionalities we can support – or we spend all of our time doing ‘workarounds’… not cool!
    4. Relational Queries – similarly, being able to query based on relationships is key. We can make workarounds, but having well tested and reliable support for a range of queries is crucial.
    5. Push (with Channels) – essential for driving user engagement, and for supporting user-user interaction
  2. Get started speed – how long does it take to get things into action
  3. Affordability – what’s the pricing model going to be in the short, mid and long term
  4. Community Support – nothing says ‘fast’ like being able to cut and paste a highly voted code snippet that does just what you need from StackOverflow or a GitHub repository!
  5. Company Viability – is the company gonna be around 12 months from now?
  6. Migration Strategy – what can we do if we need to migrate to another service, build our own backend or the company disappears?
  7. Client perception – this depends a lot on the client, but the mildly tech-savvy client may care who is looking after their data

In general most of the platforms offer some sort of ‘cloud code’ solution for backend logic, but we prefer to avoid using this as much as possible as it creates migration challenges in the future. Typically on Parse we’ve limited ourselves to duplicate object checking only. So our analysis is focused on the provided SDKs and the default features of the backend.

It’s also important to consider the Reliability & Scalability of your provider. We haven’t been able to find much useful data in this area so we’ve considered all the backends to be pretty similar in this regard – but more research is definitely required.

Our detailed analysis for each platform is in the tabs at the bottom of this post, but for the tl;dr generation – here’s the conclusion first!

Evaluation Overview

After reviewing each of the platforms in turn – we came up with a rudimentary scoring system to compare the platforms:

BaaS Evaluation Summary

Get Started Speed5333
Community Support4433
Company Viability4443
Migration Freedom4441
Client Perception3443


Based on numbers alone, we have to say that both Parse and StackMob have strong offerings and depending on your particular needs you could get better features but with pricing issues from Parse, or a sustainable business model but with some feature limitations from StackMob. If StackMob can support Relational Queries in the near future then for us it would be a no-brainer to use them for almost all of our projects. We could abstract out the CoreData scaffolding pretty easily to improve the Get Started Speed – but without relational queries it really will depend on the needs of your project whether or not it will be suitable. This is the case for all the Parse competitors though – surely an opportunity for someone to take the lead here?

We’re very impressed with the range of features provided by QuickBlox modules – and for many simple applications dropping a QuickBlox module in could be just the ticket. They really need to work on their documentation though.

And while Kinvey‘s slick website elicits confidence in the offering – the language and pricing model leave a fair amount to be desired.

So there is no clear winner… Our message to each of the platforms in turn is then:

  • Parse - API pricing is lazy on your part and difficult for us to package up on client projects. Find a way around this and you could be a clear winner as the rest of your platform is first class.
  • StackMob - support relational queries and simplify your SDK and you could lead the pack.
  • Kinvey - support relational queries, simplify your SDK and improve your pricing model and you have potential to be the market leader
  • QuickBlox - keep doing what you’re doing with the impressive selection of modules that you have, but don’t forget your CustomObjects – it’s essential flexibility needed for us to approach custom jobs. Add better relations, relational queries and tidy up your documentation FTW! Oh, and don’t forget import/export functionality from the dashboard too!

This is an exciting time to be a developer, the services that we have access to & the tools we develop with are really state of the art and the only thing limiting what we can do in an App is our imagination. We’d love to hear which Backends others are using – especially if you can shed some light on the weaknesses we’ve identified. Leave a comment below to let us know what you think!

Parse is essentially our benchmark and the platform we know best – here’s what we like and dislike.


In our assessment, Parse has by far the best SDK and most complete feature set. On-demand field & class creation, automatic anonymous users and block-callback based APIs makes Getting Started really easy. The SDK is self contained – meaning that the model objects are all instances of either PFUser or PFObject, and the features are provided through PF classes such as PFQuery, PFPush and so on. Check out how easy it is to update the user’s geolocation on the backend for example:

[PFGeoPoint geoPointForCurrentLocationInBackground:^(PFGeoPoint *geoPoint, NSError *error) {
    if (error == nil)
        [[PFUser currentUser] setObject:geoPoint forKey:currentLocation];
        [[PFUser currentUser] saveInBackground];

Super simple! The object model supports relationships (through direct reference, collection types and many-many relations through PFRelation) and complex cross-relationship queries. Check this out for finding nearby users with an overlapping set of tags:

NSArray *currentUserTags = [[PFUser currentUser] objectForKey:@"tags"];

PFQuery *query = [PFUser query];
[query whereKey:@"objectId notEqualTo:[[[PFUser currentUser] objectId]];

PFGeoPoint *ourLocation = [[PFUser currentUser] objectForKey:@"currentLocation"];

if (ourLocation) [query whereKey:@"currentLocation" nearGeoPoint:ourLocation withinMiles:25.0];
[query whereKey:@"tags" containedIn:currentUserTags];

results = [query findObjects];

Parse is also great for backup & migration strategy – a couple of clicks in the Dashboard and a link to a JSON dump will appear in your email shortly after. We see this as a great strategy for startups – keeping their MVP flexible on Parse, but migrating away to a self hosted service once the product-market fit is right. With the Facebook purchase and their market leadership we consider their viability to be pretty strong – and the community support on StackOverflow and their own site is very good.


Our primary concerns with Parse stem from their billing model. It can be very challenging to quote a project to a client when the API volume will be very dependent on their marketing activities. If you price this in as a variable cost that you pass on to the client, there is a high likelihood they won’t understand it – and concern that they have no ability to understand or control their budget expenditure will put a fast end to the proposal. On the other hand, if you try to package the API volume based on more ‘client-friendly’ parameters, then you’re taking on a pretty big risk in case your calculations are off – or a late change in requirements changes the API budget without you realising…

This is a bigger problem than it may appear at first – the prospect of 1 million API requests free of charge every month may seem like it’s a panacea, but let’s look closer at those numbers. From a real project we pitched we were assessing Parse as a backend for a taxi-dispatch application. The requirements meant that we would need near real time updates of taxi locations for a fleet of around 300 cars. Assuming 8 hours shifts 5 days a week – that’s 12,000 driver hours a week. If we update their location once every minute – that’s 720k API requests per week! Suddenly a million seems pretty small…

Our second major concern has been in client perception – with the Facebook acquisition we’ve already had semi-knowledgeable clients respond with ‘we don’t want facebook hosting our data’… Perception IS reality and this is a difficult fight for us to win on Parsebooks behalf…

Comparing StackMob now to when we last looked at it the improvements are very impressive. As a company their attitude and appetite for moving forward are palpable – right down to a ‘migrate your Parse app to us‘ campaign right after the Parsebook announcement! However, while features-wise StackMob positions itself as similar to Parse, for developers the reality of implementation is somewhat different.


The key strength that we found with StackMob is their pricing model. Basing the pricing around features makes a whole lot more sense to us than pricing per API controls – since we can control the features we use, but we can’t control the usage… So big bonus points here for the Free tier. I wish their SLA and Enterprise pricing were more transparent however, as hiding this information behind a registration-wall is a bit annoying.

In most other areas StackMob is up there with Parse - community support is good, documentation is high quality and the samples are easy to follow and reuse.


After porting one of our test applications to StackMob we feel the biggest challenges are:

  • CoreData based model – We love CoreData, but building on top of CoreData with a remote persistent store model places an unacceptable burden on the ‘Getting Started’ speed – there’s a lot more scaffold and boilerplate required than with Parse
  • Queries don’t traverse relationships – this is a big gap in the service offering, without relational queries there are a whole bunch of really useful features that are extremely troublesome to implement efficiently.

Kinvey is an ambitious company from Boston, with three major customer groups – Developers, Enterprises and Agencies. We focused on the offering for developers since this is most comparable to the other services. Securing a $5m Series A round late last year we should expect to hear more and more from them as they grow. Their recent CIO vs CMO in Mobile report made interesting reading.

Kinvey has an interesting ‘per user’ pricing model (as well as an option to revert to Parse-style API charging…) While this is certainly easier to represent to clients than the per-API model, the rate of growth in charging seems quite steep – $7/month per 1,000 active customers up to 50,000 customers – who know what happens after that level?

As of the date of writing, their website also proclaims “Once you pass 100 users, you will incur a monthly charge of at least $20 until you remove your app.” Maybe I’m getting overly sensitive and sentimental in my old age, but this doesn’t seem particularly friendly or encouraging…

Ultimately transparency of pricing is really important for us to make good decisions about platform choice – I’d encourage all BaaS providers to take a lead in this area!


A unique offering from Kinvey is the integration with other data providers. Want to integrate Google Places, foursquare or other location databases with your location-based app? Their SDK provides a homogenous interface for all Data providers which makes adding new providers into your app a breeze.

Similarly their DataLink for Oracle®, Salesforce CRM™ and Microsoft SQL Server® could be a strong selling point for developers serving the enterprise market.

We also really like the Progress callbacks from the SDK. All of the SDKs we’ve looked at have a completion/failure callback of some kind – mostly block based – but Kinvey‘s additional progress callback is pretty neat in order to build better and more informative UIs if you have any operations that might take a while.


Kinvey allows you to add any model object into their backend through adopting the KCSPersistable protocol. On the surface this seems really flexible and open, but for the purposes of getting stuff done quickly it means a bunch of boilerplate and scaffold code is required – although it’s a bit less than StackMob, and there’s the option of using NSMutableDictionary for simple objects.

In general we found the SDK to be somewhat confusing, with a fair amount of ‘do this, unless this, in which case do this instead’ in the documentation. Check out this comment from the documentation:

+kinveyPropertyToCollectionMapping keys must be the backend name, and NOT the client object property name (unless they are the same). However the KCS_REFERENCE_MAP_KEY keys specified in +kinveyObjectBuilderOptions must be the client object’s property names NOTthe backend field names.

It all makes sense because the backend names and client object property names need not be the same – BUT surely this is an exception rather than the rule? In the general case we’re shooting ourselves in the foot having different names – yet the documentation is littered with comments like this precisely because of this edge case… Ultimately this will lead to more time reading the documentation than coding, and more time in the debugger figuring out what’s going on.

Finally, as per their documentation – References “is not a true replacement for object graph management, and thus has a few limitations, which we will incrementally lift in future releases”. Here’s hoping for relational queries in one of those future releases!

QuickBlox is a UK based startup providing mBaaS services. With $2.2m in funding according to CrunchBase, although it looks like $1m of that might be a duplicate entry in CrunchBase, their offering is a modular backend built around 7 modules: Users, Chat, Location, Content, Ratings, Messages & Custom Objects.


We really like their Free Tier! “10 Gb traffic/storage, unlimited API calls, unlimited push notifications per month!” If you go over that, you can arrange to just pay the EC2 pricing + 10% overhead. Seems pretty simple for most of our apps.

Realtime messaging/chat/video-calling is a clear differentiator compared to the other offerings.

A wide range of samples are provided – making it easy to get started by adapting a previous sample.


Having to create entities on the backend before you can use them in the App gets a bit old quickly… While Parse‘s ability to create-on-demand has certainly gotten us in trouble occasionally before (capitalisation differences causing new classes to be created etc…) the win is in prototyping and execution speed – a round trip to the website for each object & schema change is a significant speedbump.

The documentation is really not up to par with competitors’ offerings. Often the iOS documentation just points you to the REST API and the developer has to work out how this will be represented in the iOS SDK. Not difficult but an unnecessary step that will cut into your getting stuff done time…

Custom Objects are the bread and butter of a lot of services that we want to create if they’re not already provided by an existing module. Unfortunately the only supported relationship between Custom Objects is a parent child relation and Relational Queries are not supported – thus limiting the range of features that can be easily implemented without complex workarounds or inefficient local processing.

There didn’t seem to be any Custom Object import/export facility – so migration could be an issue, and those rich modules are going to be a significant lock-in if you rely on them too heavily.

Finally, the SDK is based around delegate callbacks instead of Blocks. For getting things done quickly, Blocks are the clear winner and delegates just seem so inefficient and unwieldily.

About ikuramedia

ikuramedia - The App Specialists


  1. Pingback: BaaS Selection for Fun and Profit | Mobile + Cl...

Leave a Reply to Steve Price Cancel reply