In the world of mobile computing, nothing aside from Android vs iOS has sparked more debate than Native vs HTML5 code for the creation of apps. Both Android and iOS devices, the two most popular mobile platforms, are capable of consuming and displaying rich web content and media. This includes text, images, and video, which are the basic building-blocks of any app. Furthermore, both operating systems are able to run, parse, and execute Javascript. Javascript is a language created to be executed by browsers and enrich our web experiences by making sites interactive. The best thing about Javascript is that it is written once and can be executed on almost any desktop browser as well as almost every mobile browser. With Apple’s adoption of the V8 Javascript engine, execution on iPhone and iPads is faster than ever.
That’s incredibly appealing isn’t it? Write some Javascript here and there and bam, your app works on mobile and web! So not only have you saved development time, but the amount of money spent on development is going to be significantly lower. Now before everyone runs off to find a web developer to make the next big-selling app, let’s walk through a simple scenario.
A client has come up with an app idea that they want available on all mobile devices. The client hires a web developer to create the app. The app displays some pictures and text, has a user signup, and lets you send information to Twitter. The app is published and links are sent out, everything seems to be going great. However for version 2.0 the client decides that the app should be able to take pictures. Simple enough, right? Every major app out there is able to take pictures and store them somewhere. Well the developer searches through the Javascript documentation to see how to pull up a camera and take a picture, but suddenly finds that there are no documents out there on how to do so. Why? Because it is impossible.
This is one of many situations of an API that Javascript cannot access. Several other APIs include the microphone, filesystem, iCloud, contacts, calendar, push notifications…the list goes on. These are sometime critical features for apps. Who would use Instagram if they couldn’t take their own photos and upload them? What about Shazam and its use of the microphone? If either of these apps had been made in HTML5 they would have been useless. Now every day progress is made on bringing these APIs to HTML5 for use in web apps, but it will never have priority over the native system. Ever.
But say our client changes his mind on the camera. The show can go on without it. After the app picks up and is starting to spread there starts to be more and more content being created. There is a ton of rich text and media to be consumed. But, all of a sudden, the complaints start to roll in. Words like “sluggish,” “stuttering,” and “slow” start appearing. That’s no good. The developer looks into it and finds that the stuttering and slowness happens when a user scrolls a list. Well there isn’t any way to control how the phone performs a scroll, so they just have to deal with it. But pretty soon those reviews are going to make an impact on how users perceive that app.
Why is performance worse when displaying HTML? Because as stated before, native always gets priority. The device has to download the HTML, parse it, render it, display it, then manage it. That’s a lot of work. With native code all the phone has to do is render because it knows everything else about the content and layout already since it is already loaded into the app. Now there are tricks to improving HTML rendering and responsiveness, but they will only go so far.
The story of Facebook’s redesign is a great example of starting with an HTML5 app and eventually shifting to native code due to pressure from users. There has been a lot of debate on Facebook’s switch from tech bloggers, but users have poured out their support of the changing claiming that the app finally feels better.
So in the end, why is native code better? Because it is native to that device. That is how it is supposed to be run and that is what will always receive priority before HTML. For the sake of your users and your sanity, start with native and end with native. Don’t give it a second thought because your users should always come first, and your users want native.
