Making sense of Mobile Development Platforms

Mobile development platforms are so hot right now that even video ad networks want to launch one. “App cloud” is to 2012 what “pet food” was to 1998.

Why?

Firstly, mobile app development is exploding – Gartner said app store revenue would reach $15Bn in 2011 – because consumer attention on mobile devices is shifting to apps, away from the web.

But mobile app development is hard because you need to know all sorts of different languages: Objective-C for iPhone / iPad, Java for Android. And any serious app needs a remote data-store so you get into the business of provisioning servers and write Ruby, PHP or Python.

So mobile apps are a big deal, but technically complex. That’s why development platforms are springing up to help developers build them. But how can we make sense of them all? Here’s one attempt:

Mobile Development Platforms, made unnecessarily complex

Kudos to Kinvey and RWW for making this attempt and this graphic does in fact contain all the top mobile platform companies. But unfortunately, this doesn’t really help a developer trying to decide what they need, much like London Underground maps makes little sense to foreigners.

The Simple VersionTM

So let’s really boil this down to make it simple. Basically, to create a mobile app, you need some code that runs on the server-side (the cloud) and some on the device.

Ok, let’s talk about the cloud bubble.

The back-end is all about aaS

The simplest server-side (aka back-end) is where you don’t actually have to write any code – instead you call some remote API that provides the service using code someone else has written. This is a BaaS – a backend-as-a-service – and examples are Parse, StackMob or MongoHQ for data-store, Pusher for notifications.

They are the top level in the server-side stack and provide the maximum ease for developers. They often provide an iOS or Android SDK so you don’t even need to deal with the mechanics of calling their server-side APIs directly with an http request.

But if they don’t provide the exact features you need so you want more flexibility, then you have to go lower in the stack and write some code to handle your server-side logic.

At this point you decide whether you want to customize a Rails or Django setup, or if you just want to write Ruby and Python and be done with it.

In the former case, you’ll want to provision a server on Amazon’s EC2 (Infrastructure-as-a-Service) and start installing software. In the latter case, you don’t need to. You can just use a Platform-as-a-Service, like Heroku or Google App Engine, that provides a Rails or Django runtime out of the box.

The client-side is native, or HTML5, or something in between

The code you write on the client-side is going to be deployed to a device that is going to be running an Operating System such as iOS or Android.

To create your app you have 4 different approaches to choose from:

1) Pure native

(top-left box)

This is where you write Objective-C on iOS and Java on Android. The upside is that you can use the full-power of the device and have the maximum flexibility in how your app works. The downside is that you need to create and maintain multiple codebases if you want to support multiple platforms. And, if you’re a web developer, you need to learn new, strange languages that need you to get yourself setup to compile.

2) HTML5

(top-right box)

Instead of writing a mobile-specific app, you could just create a website using HTML, CSS and JavaScript and just make sure it looks good in mobile browsers.

There advantages of this approach are that you can use standard web dev technologies and only need create / maintain a single codebase. Also you can use a whole bunch of JavaScript and CSS libraries such as jQuery Mobile, Sencha Touch, HTML5 Boilerplate etc. Awesome!

But there are serious downsides:

  • You can’t get distribution in the App Store and Android Marketplace
  • You can’t use powerful device features such as the camera and notification center
  • Your user-interface will probably look website-like and not app-like
  • Users will have to remember to navigate to your website in their mobile browser (a pain to type in the url) rather than just having a nice app icon on their homepage

Those disadvantages are show-stoppers because consumer attention on mobile is moving to apps away from websites.

3) Hybrid

(top-middle box)

Hybrid apps use a combination of native and HTML5 to reduce the trade-offs between them. Typically a hybrid app consists of HTML5 code running inside a provided a native Webview component (like a mini web browser) with all the advantages of (2). But there are two native elements also:

Firstly, there is some kind of ‘native wrapper’ which lets you distribute your HTML5 code as if it were a native app, so you can get distribution in the App Store and Android Marketplace.

Secondly, there is a ‘native bridge’ which allows you to access native features such the camera and notification center, but still writing your code in JavaScript rather than native languages.

Some hybrid development frameworks even let you write your own native code if you really want to, sitting side-by-side with your HTML5 code so you can mix and match as you like. Examples of development platforms for hybrid apps are PhoneGap, Appcelerator and Sencha Touch 2.

Great right? However, there are still downsides:

Complex development process:

To get the best of both HTML5 and native, some frameworks need to sacrifice the simplicity of the development process.

For example, with Appcelerator, you need to use their own IDE. And to use PhoneGap’s open-source native wrappers, you need to set yourself up for local compiles in Eclipse or XCode.

If you use a cloud build service, such as PhoneGap Build, you save yourself from needing a particular IDE or setting up for local compiles. But instead you need to zip up your code and upload it into a web form and wait several minutes while your native apps are queued and built, then download them from the web ready to test.

Not a great build / test cycle if you’re used to updating your HTML and JavaScript, hitting refresh and immediately seeing the results.

Bad UI:

Users can tell the difference between an HTML5 app and a native app, and the latter are inevitably better.

Frameworks like Appcelerator accept this reality and give you a true native UI even if the development process sucks. With Sencha and PhoneGap you’re left to make your HTML5 look like native, which can come close with a lot of effort, but can never quite be as good

That’s why you should go with Trigger.io

4) Awesome Hybrid by Trigger.io

(big box in the middle)

These problems with existing client-side hybrid frameworks are why we founded Trigger.io. We provide both a super simple development process and genuine native UI components. We’re the only mobile platform that provides this, and judging by our growth and the quotes we’ve published on our homepage, developers like it.

The reason we can do that is we run a cloud build service so you don’t have to setup your machine for local compiles but we can still add genuine native features. And we’ve been smart about building it so incremental builds take < 2 seconds, making for a very nice development flow.

Check out our screencast, or judge it for yourself by signing up for free now.

Summary

We hope this has helped you make sense of mobile platforms being able to categorize them as making the server-side or client-side part easier, and then breaking them down further within those categories.

Questions? Thoughts? We’d love to hear from you at support@trigger.io and hope this inspired you to try our hybrid app development.