How to choose between native, hybrid, and HTML5 mobile app platforms

For those undertaking new mobile initiatives, and weighing what platform to choose (natives, hybrid, or HTML5), here’s a little framework you can use to help you decide where to invest.

Deciding on an app platform

So if you’re reading this, I likely don’t need to convince you that we’re squarely within a tectonic shift in computing platforms, as we move from desktop web to a range of mobile devices. If you’re building a serious, internal, long-term development competency to address this, there are many decisions to make; the consequences of which can dictate your path for some time to come. These decisions include balancing factors such as time time to market, resourcing, flexibility, and extensibility for what is coming “next”. At the crux of this decision is choosing the right platform (e.g Android, iOS, HTML5, hybrid, responsive web site).

A quick framework for you

At the recent FutureM / Inbound conference, I was on a panel discussing this larger theme of “appification” and spoke about an internal framework I’ve used to help with the platform decision — due to feedback I’ve received, it seemed worth sharing more broadly:

The crux of the model is that you should select your platform depending on what you’re trying to achieve for your customer, balanced alongside your internal resourcing.

On the “X-Axis”, we plot how “validated” the customer need is for what you’re planning to build; if this is a brand new product this may likely be “unvalidated”, whereas porting a thriving web experience to a mobile platform, we may call that “validated”. On the “Y-Axis”, we plot how well resourced your company to achieve this objective – whether that be financial resources to develop the required team, or skilled resources.

Let’s look at each resulting quadrant, in more detail.

Quadrant 1: “Go full force”

If you’re in this quadrant, then you really have “first world problems“, in that you know what you need to do, and have the resources to execute on it. In this case, I’d strongly recommend to build on all native platforms where you have a significant user base; for most cases this is iOS and Android, where a responsive website can suffice for the remainder of mobile traffic (e.g. BlackBerry). You can validate this choice by observing your current traffic and playing to where >80% of the mobile traffic comes from.

Keep in mind, when developing for two platforms simultaneously, your engineering overhead will more than double. While certain requirements are stable across each platform, each platform requires platform-specific oversight and tooling, as well as testing and rollout. Don’t underestimate how taxing context-switching can be, in this context.

Quadrant 2: “Play to your strengths”

In the event where you possess sufficient, and qualified, development resources, but lack a validated model, I’d recommend developing native iOS first. At this stage, there is a temptation to use a “cross-platform” approach, like HTML5; however, this will simply deliver a subpar experience across all devices.

Likewise, the reason not to go “Android-first” is that the maturity of the Android ecosystem for their core APIs, 3rd party tools, not to mention the high fragmentation of devices and OS versions must all be accounted for. As a result, you’ll be able to develop faster in iOS, and validate your product, against a larger audience of early adopters, with a higher propensity to upgrade to the latest OS versions. That said, keep in mind app store submissions may slow you down; however, with the latest TestFlight rollout from Apple you should still have sufficient scale to help validate your model.

Quadrant 3: “MVP-mode”

In this quadrant, you should be more apt to take a classic “lean” approach. That is, without a validated model, and no resources, you should be putting things out for customer validation as quickly as possible, and held together with duct tape & chewing gum if you must. In models like this, once you graduate out of a “low-tech” solutions (e.g. landing pages, WuFoo forms, emails, etc.) use whatever you can as fast as you can.

Here, responsive web pages, and app frameworks (e.g. Appcelerator, PhoneGap, Xamarin) become a solid option for you. At this point, choose whichever one can get you to a product you can test with users as quickly as possible.

Quadrant 4: “What are you waiting for?”

If you have a validated model, but have not committed resources to developing a mobile competency, then you’re certainly in a very odd conundrum. Perhaps this is solely an artifact of this matrix, but if you really are in this quadrant, then I’d suggest doing whatever possible to raise or redeploy additional resources to address your mobile competency ASAP.

There are of course exceptions, but the basic approach should hold

As with any framework like this, there are of course exceptions. For instance, apps that leverage particular features of a platform (e.g. Apple Pay) or address specific markets (e.g. the developing world) have specific platform requirements which will largely dictate your choice of platform. However, the key here is that simply having a presence on a specific device should not be the goal — rather having a specific, tailored user experience for your customers and the ability to execute on your vision.