Hybrid Apps are BS

John Allsopp
Web Directions co-founder
Tweet

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.

  1. Native apps can run offline.

    Um, hang on, so can web technology based apps on most platforms.

  2. 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.

  3. 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.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://cloudfour.com/blog Jason Grigsby

    Performance is, unfortunately, a legitimate issue if you decide you want to mimic iOS interfaces.

    The main obstacle is the inability to use position:fixed on the viewport instead of the document. You need that capability in order to mimic navigation bars pinned to the top and/or bottom of screens.

    You can get the navigation bars to stay where you want, but the moment you do that, you fix the whole screen and have to intercept all of the touch events. This requires you to re-implement scrolling behavior in javascript. This is where libraries like iScroll come in.

    Unfortunately, even the best performance tuning with iScroll is still going to feel slow on older harder in our experience. We found this to be true particularly on first generation iPod Touches and iPhone 3Gs.

    The reality though is that the speed of chips is increasing fast enough that even if we continue to have to handle scrolling in JS (which I doubt) that the mobile device will likely perform sufficiently.

    FWIW, I wrote a similar article on the five most common arguments I hear for native iphone development:
    http://www.cloudfour.com/the-five-most-common-arguments-for-native-iphone-development/

    • http://webdirections.org John Allsopp

      Interesting that within hours Joe Hewitt posts Scrollability

      http://joehewitt.github.com/scrollability/

      on my iPhone 4 it is well slick – a little jankie on iPhone 3G – but everything is!

  • Bernhard Hofmann

    Excellently written and rings very true with my opinion that I could not have put so succinctly.

    Just one thing I noticed amidst the almost poetic flow of your writing. You wrote “Users could care less”. I think you meant to say they “couldn’t” care less.

    The only reason that stuck out is because the rest of the blog is so well presented. Thank you for a reference we can now use to silence the debates on Native versus Web technology apps.

  • http://www.josscrowcroft.com Joss

    So glad somebody cleared this up – now I have something to point clients to :)

    awesome read.

  • http://webdirections.org John Allsopp

    Thanks Jason,

    really appreciate the detail. it’s interesting how one small thing, in this case the absence of support for Fixed positioning has such a big implication on performance.

    Bernhard – thanks for the thoughts. The phrase “could care less” is a particularly American expression, which is taken to mean exactly the same as “couldn’t care less”. It’s nonsensical, but widely used

    http://www.worldwidewords.org/qa/qa-ico1.htm

    Thanks Joss! Let us know how it goes ;-)

  • Stefan

    “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.”

    Always thought that Appcelerator is JavaScript-only since V1.0…

    • http://subprint.com Joe McCann

      You are correct. Titanium mobile requires you write the *entire* app in JavaScript and then it cross-compiles to the native platform.

  • http://www.jansch.nl Ivo Jansch

    Well written. A while ago I wrote a piece where I compared the non-native solutions to instant coffee. While adequate for many situations, it’s never as great as freshly made coffee, but freshly made coffee will on the other hand be slightly more expensive. The post is at http://www.egeniq.com/2011/01/17/instant-coffee-in-the-mobile-industry/

  • rsanchez

    I think the webOS definition of hybrid app is more clear-cut. Yes, they define “native” as an app written in C/C++, which you have problems with. However, in the webOS ecosystem, hybrid means an app written using both web technologies AND C/C++. Your C/C++ program lives as a plugin, which you initialize using an tag. If you need performance with the ease of building a web UI, or if you are concerned about people seeing your code on-device, you have core functionality in a “native” plug with standard JS/HTML/CSS handling the UI.

    So in short, on webOS, native doesn’t simply mean installed on-device. Native is anything compiled for the device’s ARM architecture (which can be easily done with C/++), and a hybrid is an app that combines web technologies with native functionality.

  • http://rosshadden.com Ross Hadden

    I have to admit, the title and opening paragraphs were scaring me senseless, as I was palpably excited when I found Phonegap: finally a way for me to apply my self-proclaimed area-of-genius to creating Android/iPhone apps. And the entire time I was reading, since I had it predetermined in my mind that you were going to say “Don’t use technologies like Phonegap!”, I anticipated that you would either persuade me that “hybrid apps” were bad, or I would disagree with your argument entirely. By the end of your article I realized there was no need for concern, for we are on the same side! You weren’t dismissing hybrid apps, merely the labeling as such. Just goes to show how provocative and engaging titles can be :-D.

    • http://webdirections.org John Allsopp

      Heh

      sorry to give you a scare – though it was also the intention ;-)

  • http://bradfrostweb.com Brad Frost

    Well-written perspective. We web guys often get into lengthy discussions with the native guys at work about the merits and downfalls of each solution: web only vs hybrid vs native. Ultimately, for our clients it becomes a business decision. Do they want a more refined experience or bigger reach? Do they 100% need to access device APIs or can they have a more solid basic experience online (often times clients/creative directors get blinded by the stars in their eyes: “And when you shake the phone, unicorns will fly out of the page!”)

    I totally agree with Jason’s point on iScroll and fixed positions. It’s something everyone wants and can’t get with web technology. Unacceptable in my book.

    At the end of the day, companies should have more comprehensive mobile strategies, with solid web experiences as well as finely-tuned native apps. However, today’s budgets don’t allow this, so we’re unfortunately forced to choose.

  • http://twitter.com/monteslu Luis

    I have to disagree with you on “could care less” meaning the same thing as “couldn’t care less”. Being widely misused doesn’t mean use should use it.

    Otherwise fantastic article :)

    • http://webdirections.org John Allsopp

      Thanks Luis

      many language constructs are essentially meaningless. I see the expression “could care less” (which is widely used) as being less aggressive than “couldn’t care less”.

      I read the phrase as “I could care less, but choose not to”.

      Regardless, it is a widely used expression, at least in the US.

      BTW, in languages like english, a double negative is a positive – I’m not not well, means i’m well. In Classical Greek (and I’m sure other languages) a double negative is an emphatic negative – I’m not not well would mean – I’m really not well.

      Language is about rhetoric and tone as well as strict grammaticality ;-)

  • David Frahm

    Its fine to say that “hybrid” doesn’t make sense, but seriously we DO need some standard terms to describe the fundamental difference between an app from an appstore built just for that platform, and one on the web (that can have the same functionality).

    A lot of information here was useful, and I basically concur with all of it. However, lets offer some solutions.

    Native apps could be: Platform apps, ???
    Web apps could be: Open apps, Universal apps, Universal Web apps

    Perhaps for end users, maybe “web” isn’t so wrong? To them its referring to where the app is installed from, not that its built using HTML+JS+CSS.

    • http://webdirections.org John Allsopp

      Hi David,

      the term “hybrid” typically applies to an app built with web technologies, packaged and deployed to be installed from an app store “just like a native app”.

      The article is a long winded way of saying that these *are* native apps.

      The other I’d call web apps.

      What i’m really focussing on is abandoning the term hybrid, which I think is a way of diminishing certain native apps – namely those built with web technologies.

  • Frank

    I would define hybrid as any app that uses a combo of local and web based tools, regardless of how it is built. I think you are focusing too much on the how it is built part and not the what it does.

    • http://webdirections.org John Allsopp

      The reason i’m focussing on this is I believe hybrid is a term used to diminish the value of using web technologies to develop native apps. Arguing that the the hybrid is essentially meaningless is in fact focussing on precisely what it does, and not how it is built – using the term hybrid does the opposite – focussing on the tech used to build it, not the outcome.

  • http://heroesdesign.net/cartcake desbest

    I find that HTML5 is narrowing the gap between desktop and web apps, by providing functionality like offline storage, a newer javascript version, audio and video, and other such stuff.

    What I find the difference between desktop and web applications, is that web applications are restricted by the technologies of the browser, whereas desktop applications can extend on the default functionality that they have.

    Take Google Chrome OS for instance. Right now it comes with Flash preinstalled. What happens when a new plugin comes out in the next 5 years, or someone wants to install Java, Silverlight, Shockwave, or Unity on it? What happens then? You can’t install it because you’re locked into the browser, and are subjective to whatever Chrome-specific walled off updates they give, like the Chrome App Store, or the Chrome specific audio input form.

    In the smartphone world, things are rather different. Because of things like PhoneGap, Appcelerator and Rhomobile, people can use web technogies like The HTML5 Suite to build smartphone applications, rather than Java, .net framework, C++, C# and Objective-C.

  • mike Mccarty

    1. Go to maps.google.com through tor browser. google maps on your phone of choice. There’s the difference. Webapps have a long way to go still.

  • mike Mccarty

    Please note I gave the best engineered mobile web experience that I could find. If you want to make it unfair compare twitter.com to the app on your phone. Or just view any jquerymobile app.

  • Raanan Avidor

    As an app developer, the difference between native apps and hybrid apps is what language I use to write them.

    If it is written in the native language, then it is a native app.

    If it is written only in HTML, CSS and JavaScript, and it runs in a browser, then it is a web app.

    If it is written only in HTML, CSS and JavaScript, and it runs in a native shell, installed via an app store, then it is a hybrid app.

    If it is written in HTML, CSS, JavaScript and native language to write plugins, and it runs in a native shell,installed via an app store, then it is a hybrid app.

    • http://webdirections.org John Allsopp

      But why? Is something written in Unity3D a hybrid app? Is something developed in flash? Why distinguish?

  • http://webofawesome.com Nic Johnson

    As you mention, the tech is irrelevant, Provided it does the job, most users will never know if it’s HTML5/JS, Java, Objective C or interpreted befunge.

    As for the definition of a native app, it’s something that you install. You own it. It has an icon. You feel like it’s a little object that you didn’t have before, and which you now do have. You have acquired it. The sum total of your possessions has increased.

    It’s not a shortcut to a website, which is why the Chrome app store has not faired so well. It’s not a thing which obviously runs inside another thing, which is why Adobe Air has not prospered. It has to stand alone, as a thing which I can pick up and own and show to my friends.

    It doesn’t make any sense, but there it is. Technology is irrelevant.

  • http://www.jabberwikaba.com Daniel Laughland

    I have used terrible apps that were made in Xcode, and I have used terrible apps that were made with PhoneGap. I agree with you completely that a skilled developer can have success with any language if they focus on a good user experience.

    But you do ignore one important point: hybrid apps are often used to “cut corners” in cross-platform development, and this is where a lot of people run into trouble. They see something like PhoneGap and think they can get iOS + Android for the price of one, and the project fails. That’s where these hybrids get their bad reputation. If you don’t tailor your UX for the platform you’re on, no amount of hardware acceleration can save you.

  • http://www.jasonified.com Jason

    To be clear on Appcelerator, whilst you can write HTML/Javascript/CSS much like PhoneGap etc, you can also write “natively” in javascript.