Hybrid inappropriateness

The mobile development landscape is bursting at the seams with frameworks and tools that enable you to target two primary mobile platforms: iOS and Android. And the mobile community has classified these frameworks and tools into three categories: native, hybrid, and web. Unfortunately, limiting the classification to three is inadequate as the term hybrid is too generic.

Web apps are truly ubiquitous because they take advantage of the browser and are thus, cross platform. You, for the most part, can get away with maintaining one code base that can be viewed on iOS, Android, and the other minor players. Yet, the key point of Web apps is that they are web sites, not mobile apps.

As you begin to blur that mobile app/mobile website line, you’ll stumble over various issues like performance or varying behaviors depending on the underlying device. Worse, you’ll find that not all browsers are created equally and thus, you’ll need to compensate for various scenarios or use assorted compensating tools like Modernizr. Or, you’ll find yourself throwing the web app into a container because you want mass distribution via an app store or because you want to take advantage of some native feature.

And at that point, in the eyes of many, you’ve built a hybrid mobile app. But that’s not the whole story.

Hybrid frameworks aren’t all created equal. There are, in fact, two flavors of hybrid-ness: hybrid-web and hybrid-native. Both are extremely different; in fact, to showcase the difference, I need only compare the “featured” apps of two hybrid frameworks: PhoneGap and Marmalade.

PhoneGap is a great framework for building hybrid-web apps. You code in HTML and JavaScript and the resultant code is run inside of a web view managed by a native container. You ostensibly write one code base and deploy to all the primary mobile platforms. Similar frameworks are: IBM’s Worklight and Icenium. Sencha Touch falls into this realm as well when you employ their container technology.

Marmalade is a hybrid-native app platform; that is, you can code in an intermediary language like C++ that is ultimately compiled down into native code (i.e. Java for Android, Objective-C for iOS, etc). These apps are not characterized by a web view in any way. They are native, close to the bone as it gets apps. The benefit is that you only had to write one code base, the underlying tool took care of the dirty work in making it work similarly on iOS and Android, for example. Similar frameworks are: Corona, MoSync, and Appcelerator to name a few.

Now look closely at the featured apps of each hybrid framework. They’re distinctly different aren’t they?

PhoneGap and the rest of the hybrid-web frameworks are good at producing informational apps. These apps can look beautiful and certainly can have some compelling features like tight integration with social networks and geo-tracking, for example. But they’re inadequate for games and still lack a rich user experience when compared to more native apps like Flipboard or AngryBirds.

Marmalade and the rest of the hybrid-native crowd shine when it comes to highly interactive apps like games; what’s more, these frameworks can build an app that generates a wow. And therein lies the crucial aspect that’s missed when the industry blindly assumes all hybrid options are similar. They couldn’t be more incorrect – thus, we need at least four categories (native, web, hybrid-native, and hybrid-web) and we need to eschew the lone term “hybrid” as it lacks clarification and therefore has no meaning.

This story, "Hybrid inappropriateness" was originally published by JavaWorld.

Copyright © 2013 IDG Communications, Inc.