A decade ago I was giving a talk at the Polytechnic University of Valencia on how to use mobile phones in Health Care services. It was about a J2ME based application that easily collects user data and then sends it back to a server for processing using REST services. It was a simple idea by today's standards but it was attacked by many experts and people in the audience because it felt like a crazy idea. Who would use a mobile phone like that? We've witnessed how fast technology has evolved in recent years while working synergically with the Internet. Are we only limited by our imagination?
The ecosystem is completely different today. We have four big OS players (Android, iOS, Blackberry and Windows) with hundreds of devices and several programming languages with different SDKs and tools. And quite soon we'll probably have a few more (Ubuntu/Firefox for Mobile, Sailfish and Tizen) adding more complexity to the mix. We developers want to create our dream application and, of course, make money with it. Demand for mobile applications and feature updates is so intense that developers should focus their time on creating an outstanding user experience while outsourcing the non-differentiating elements such as infrastructure.
Developers also have to endure the "C/S apps life cycle". When we're dealing with a single device/OS we usually tend to develop native applications (we want the sexy native look and feel). When it's time to support new device types we work hard to provide the same business logic to all of them so we tend to switch to server-side apps. This is not new, we saw this situation more than once already, eg. with the introduction of J2ME and some old "cool" technologies such as RMI or JINI, and with devices like the first Java phones and set top boxes. When the ecosystem includes so many different devices and features out there the fragmentation gets so high that it becomes very difficult to develop for all platforms so the vendors and the market try to standardize things. That makes us go back to a common "virtual device" and, later, back to native again. But obviously after a while vendors want to offer different/extra features than their competitors so we're back to fragmentation and server side apps. IMHO the promise of "write once, run anywhere" doesn't apply anymore. Fragmentation is something that we will see often like the sun shines and what we need is some help (sunglasses? :) so the process is not that painful.
It should also be noted that server side apps usually depend on native application elements (browser, runtime, engine, etc) which can vary from device to device. So development in this context can be really tricky. Developers have endured the implementation and maintenance of Thin Clients but realized that not only the UI might require changes: there might be issues with server calls as well. We need help to live up to this situation. We need more than an outsourced platform to develop our applications but also one that ensures long term success.
So this is where MBaaS comes to the rescue. We could define it as a set of outsourced services to enable our application to manage users, data and help with monetization (saving us a lot of time by taking care of things that are not what we really envision). You focus on your brilliant idea without dealing with servers. By using MBaaS the fragmentation problem is not solved though. We'll still have to build a specific Thin Client for each type of device. But our users, data, settings and monetization configuration are shared in a secure environment. Remember that data equals money. If you need to support a new device type later you can quickly implement a Thin Client without losing your users or data.
Developing an application is a complex task but we shouldn't forget that mobile users are even more demanding than regular users and that deploying and testing require quite a bit of time and money. Competition in the mobile application space is fierce. Tons of cool apps don't ever get used or adopted. So not only mobile developers require reliable technology in order to be successful but also access to tools and services that ensure longevity. The MBaaS provider must make your life easier by fulfilling your needs.
Choosing one is not an easy task. Aside from checking that a specific provider supports the features your application needs you also want to make sure the services will scale as your users grow and that the vendor is flexible enough to go beyond mobile (eg. REST API). Support quality is also pretty important, so is accurate documentation and good sample applications (all of which will make you go faster). You don't want to take a look at the back-end source code to understand how it works. Vendor viability is something to worry about if you don't want your app to die early.I was very skeptical about developing mobile applications for multiple device types before I run into MBaaS. But after trying out Kii Cloud (developer.kii.com) I'm now happy writing new mobile apps again. I'm no longer worried about rewriting an app for new devices. It's now in fact a chance to play with and enjoy working with a new platform. Kii Cloud makes me confident that the most critical part of my app can now be reused and I don't have to reinvent the wheel.