Hybrid Apps are BS — SitePoint

Just what is a native app anyway?

“I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description ‘hard-core pornography’; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it”

Justice Potter Stewart, US Supreme Court, Jacobellis v. Ohio

Of late, there’s been much debate about the relative merits of native, web and so called “hybrid” apps, which use web technologies plus technologies like PhoneGap to create apps that can be installed on platforms like iOS “just like native apps”.

All of which leaves unanswered the seemingly innocuous question. Just what is a native app? And what exactly makes it different from a hybrid app? Perhaps we might respond as Justice Potter famously did regarding pornography, that we know a native app when we see one.

But beyond that, what rules of thumb are there?

Look and Feel

Folks like John Gruber, the incredibly widely read Apple technology pundit, suggest that native apps are intrinsically more attractive. By which logic apps that use native UI are native. So, where does that leave a great many games, for example say Angry Birds, without a native control in sight. Is it native? Who’d argue that it’s not.

And if an app built with web technologies “fools” a user into believing the list they are interacting with is a “native” list object, like the NetFlix iOS app, and many many others, why is that any less native?

Performance

Native apps, being written in “real” programming languages like Objective-C mean such apps have better performance, which of course always matters. Except when it doesn’t.

You can write horribly inefficient code in any programming language (I’ve been doing it for 25 years!), and it’s generally true that compiled languages like Objective-C give better performance than interpreted languages, all other things being equal. But while generally true, it’s not always relevant. Indeed, it’s not always entirely true.

Performance only matters when it matters, that is, higher performance matters only when it impacts the user, and not in the absolute. In graphics intensive applications, such as games, of course performance is a big deal. Stuttery, low frames per second games aren’t likely to be tremendously successful. But even here, it’s not so clear cut. On iOS, CSS animations and transitions are hardware accelerated. With no effort, a developer can hand off the animation task to the GPU, so the performance of JavaScript code may be of little, if any, real impact on overall application performance.

As WebGL comes to mobile, then the performance advantage of compiled languages becomes even less relevant. A great many of the most successful iOS games are scripted using Lua, on top of an OpenGL 3D rendering engine. With WebGL in mobile browsers, JavaScripted WebGL games will in all likelihood match the performance of current native games, even without advances like JIT JavaScript engines, which are already in Mobile Safari, and in the Playbook and Blackberry browsers.

It’s not entirely clear that, outside of graphics intensive applications, performance is really that much of an issue when it comes to applications built with web technologies. Sure, this limitation is widely touted, but evidence for such a strongly held belief is thin on the ground. Admittedly Android’s performance of CSS transitions and animations is pretty dire.

Like native look and feel, performance is in the eye of the beholder. If the user doesn’t notice, is it an issue at all?

Mind the Gap

So, if performance in many cases is not quite the issue it’s made out to be, and native look and feel is a bit of a red herring, what else might make something native? Clearly there are some aspects of a native app that apps running in a browser don’t have.

Native apps can run offline.

Um, hang on, so can web technology based apps on most platforms.
Native apps can be installed on the device.

In fact, so can web based apps on iOS and other mobile platforms, indeed with less effort than native apps; no need to go via an app store, the user can do it from inside the app.
Native apps get access to all the device goodies like the camera, accelerometer and so on.

Now, this is a distinct, though diminishing, advantage. Right now, you can’t access many device APIs directly from the browser. If you need to access the camera or address book on iOS, for instance, you’ll need to go beyond just the browser. That is the case, for now.

You can, however, using PhoneGap, Appcelerator, Rhomobile, and other similar solutions, develop your app using HTML, CSS and JavaScript, and access these underlying APIs in JavaScript, via the DOM.

And, with the emerging DAP standard from the W3C (which gives access to a great many device APIs in a standardized way, and is already partially implemented Android 3.0, where the browser can access the device camera via a DOM API), as well as widespread geolocation support and increasing accelerometer support in the browser, the day of access to many of these device APIs in the browser is not far off.

Elephant in the Room

So, what am I missing? Ah, the elephant in the living room, app stores. To get into Apple’s App Store, the myriad Android app stores and so on, you do need to package up an app built with web technologies. Sadly, you can’t simply provide them a URL, even apps built for the Chrome web app store need to be packaged.

It remains a matter of debate as to whether this is an advantage, as opposed to simply a distinctive feature (or is it a bug?) of native apps, but even still, 100% of your application’s logic and presentation can be built with web technologies, packaged with, say PhoneGap, and deployed into app stores.

The Hybrid Non Sequitur

So in all of this, what makes an app hybrid? Why are apps built with web technologies, and packaged up using say, PhoneGap, any less native than a game built with Unity3D? Or for that matter, than an app built with CocoaTouch and Objective-C? And on WebOS, where HTML, CSS and JavaScript are the native languages of development, native apps are almost all developed with web technologies.

Above all, do users care? I doubt it, as few, if any, can tell. If it works well, and looks good, they’ll use it, and if not, they won’t. Users could care less, the same attitude they have had towards most platforms for decades.

There are web apps, and there are native apps. There’s no such thing as hybrid apps. God knows where the meme came from, but it’s time to retire it. Use whatever technologies you want, or are comfortable with to build great apps for your users.