Thoughts on Shutting Down

parseIt’s less than a month since I posted about being impressed with Parse and talked about it’s “presumed longer-term continuity through being owned by Facebook” and yesterday parse announced it is shutting down.

I have always been cautious about using BaaS in production apps due to unknown service levels, uncertain longer term continuity, privacy issues and security concerns. Just as BaaS was getting my trust, it lost it again. Remember, take care if you are using a backend service provider, whatever their pedigree.

However, all is not lost. The closing of has caused the server side to be open sourced. This now provides a new way of providing for an easier server side. You get most of the advantages of Parse (no server side development and easy to use app SDKs) without the uncertain longevity risks of using a BaaS provider. I also expect a few ‘hosted parse server’ providers might surface to make the installation and setup easier and ease migration for the 600,000 developers using

My Impressions After Using BaaS

parseI recently used for the first time for use within an app on Android and iOS. I have always been cautious about using BaaS in production apps due to unknown service levels, uncertain longer term continuity, privacy issues and security concerns. However, this was an example of an app that didn’t have any of these concerns and needed the advantages of quicker and easier development. But did it turn out to be quicker and easier?

First the cost. The free tier is generous and allows up to 30 requests per second and 20Gb storage. Unless your app is for a large brand or well known organisation, it’s going to be a while before you reach these limits. The long tail of apps will never reach them. If you do, you can probably afford the subsequent pricing.

Integrating Parse in Android and iOS, using the Parse Quickstart, was trivial. An added bonus was the relatively newer offline support. This allows you to cache data locally without having to define/manipulate a separate local database. More on this in a moment. The Parse API, without local caching, ‘worked first time’ on both iOS and Android with no gotchas or issues.

The main problem with some BaaS, but not Parse, is that while it’s easy to get data in, there’s usually no or poor facility to browse database data as you can with RDBMS tools. The web UI at allows you to view and modify data but this is more oriented towards developers than it is for general CRUD performed by operations or client staff. More on this also, in a moment. The Parse database automatically adds useful createdAt and updatedAt timestamps to rows that are especially useful for testing.

The offline support saved significant development time, enabling offline data for free. However, it took some effort to get right. If you want to use this yourself, the section ‘Providing Complete Offline Support’ on the web site describes the idiomatic, asynchronously driven, way apps need to pin saved data in order for it to be available both remotely and locally.

On iOS there’s a useful PFQueryTableViewController that saves lots of coding. Fresh tilled soil has a useful tutorial how to use it with Swift (as I was doing).

While I was developing, I was invited to a new service called Adminca that can be used to create Admin panels for Parse databases. This allows you to separate developer and support/client concerns. Adminca is still very rudimentary but I can see how useful it will become as new features become available.

I came away impressed with Parse. It saved a considerable amount of effort and time. This and the the presumed longer-term continuity through being owned by Facebook, means I’ll be giving it more serious consideration for future apps.

The Latest from Blackhat

blackhateurope15If you are a mobile developer, you should take a look at the white papers and presentations that have become available following the recent blackhat Europe 2015.

Of particular interest to Android developers is (In)Security of Backend-as-a-Service (pdf) that shows how hard-coding service credentials for services such as Parse, Cloudmine and Amazon AWS not only puts particular user’s data at risk but the whole platform at risk. The easily-obtained credentials can be used to access huge amounts of sensitive data. The apparent ease of using BaaS has caused mobile developers to cut and paste sample code without thinking of the security implications.

Wondering what else your app might be doing wrong? The AndroBugs framework presentation allows you to scan APKs for known coding mistakes. It decompiles the app and looks for bytecode patterns that signify vulnerabilities in the code. Androbugs has recently become open source on GitHub.

Another way your app data might become visible is if it’s stored in the OS sandbox and subsequently backed up either on a rooted device or via ADB. The presentation on Authenticator Leakage Through Backup Channels on Android (pdf) goes into a lot more detail.

As usual, black hat activities look into the problems but don’t give many ‘white hat’ recommendations how to fix apps. It’s easier and more fun to find problems than it is to provide fixes. If you are looking for some answers then my site provides some recommendations.

Mobile Backend Starter

google.gifJust over a year ago I wrote about Backend as a service (BaaS) and warned people to be careful and do their due diligence. My main concerns were over service levels, scaleability, data visibility, calculating costs and long term continuity of service.

Well, Google have quietly released a BaaS for Android developers that seems to solve most of these concerns. Mobile Backend Starter, announced at Google I/O, became available yesterday that uses Google App Engine. It allows you to easily setup a backend for data storage, authentication and messaging (GCM). An example client is also available.


It all looks good. However, most companies need to centrally manage both Android and iOS data on the same server these days. Also, I wouldn’t know how to go about predicting costs. Finally, what with Google recently shutting down some services, I no longer trust Google to support all their offerings into the future. I can see Mobile Backend Starter mainly being used for small ‘homer’ projects. That’s homer being ‘at home’ rather than Simpson!

If you are interested there’s a walkthough on Brad Abram’s Blog.

Backend as a Service

kinvey.pngThere’s a growing number of hosted services that allow you to concentrate on your smartphone apps while leaving the server-side to someone else. The idea is that custom scalable, secure and managed services are difficult and costly to create so instead you piggy-back on a service that has already solved these problems. There’s a useful new blogpost and infographic (png) at kinvey that depicts backend providers, service providers and their inter-relationships with mobile SDKs, mobile APIs and handset OEMs.

If you have a hobby project or proof of concept then this type of service is great to get you going quickly. However, if you are offering a commercial app you should do your due diligence. Here are some things you should be thinking about…

  • As with any service is there any guaranteed service level?  Have there been any outages?
  • Is the service really scalable?.  Find out how. What about required bandwidth and I/O?  I say this because some services say they are scalable just because they run on Google/Amazon cloud services. This sometimes isn’t enough.
  • Can the service deal with surges in use such as that required when a service is launched?
  • How easy it for you to actually see your data for reporting, admin and backup purposes? If not, you will need to write extra software to do these things.
  • How much will it cost in the long term if you really do get very many users?
  • How long is the service likely to be around? How is it funded? Is it experimental or commercial?  I’d prefer paid to free as at at least you know they are getting income to help continue and improve the service.