The Promise of HTML5
HTML5 promises to reduce time to market by allowing web developers to quickly build a mobile application using the tools they already know while leveraging existing code (usually a mobile-web app already in existence). It also allows developers to build an application once, and deploy it on tens of platforms: iOS, Android, Blackberry, you name it.
With native development on the other hand, there is little shared code between platforms such as iOS and Android, and one often needs to shun smaller platforms such as Blackberry or Windows 7 because of high costs associated with per-platform development. Since the applications are developed independently, their development and release timelines will never line-up properly, and one never wants to release features solely to a single platform.
It would seem like HTML5 would be the way to go for easy, cheap, and fast app development.
While great in theory, just like any web development, with HTML5 apps, things never go as planned. When building HTML5 mobile apps, the application is rendered using the device’s web browser. The application is therefore subject to all the weird quirks associated with the web browsers of the various devices it’s deployed on.
There are many mobile development platforms that offer HTML5 mobile application platforms. Some such as Appcelerator and PhoneGap even claim that they create “Native” apps. All these platforms tout their strengths in allowing the quick development and deployment of mobile applications. Yes they allow you to quickly build and deploy a mobile application, but boy will you be disappointed with your final app.
Remember back in the 90s when people were building websites with Yahoo! GeoCities and Dreamweaver (when it was still a Macromedia product)? These websites websites could get pretty advanced, but they could never breakout of the template format used for development. This exact problems plagues all HTML5 based mobile application platforms – there’s only so much you can customize.
Getting the experience right using HTML5 on a mobile device takes hundreds of iterations, most are wasted getting functionality and speed to match truly native. After all this hard work and energy, you’re finally deep in the development of an HTML5 mobile app. When you begin hard testing the app, you’ll notice you’re always finding small glitches and weirdness at times, and the slow performance is instantly noticed by users. You don’t get the WOW you were hoping for from your users – they’re never fully satisfied.
The hybrid approach
Remember Appcelerator and PhoneGap we mentioned above? Well they’re application platform builds apps that fall into this hybrid category. They leverage some native code for things like cool effects/transitions, hardware access (camera, compass, etc.), and push notifications. They’re part of the problem. By claiming they build native applications when in fact they don’t, they confuse people into believing their apps will run as smoothly as native apps such as Path or Tweetbot.
Lets not forget the devices your users will be running these apps on… You may be testing your hybrid or HTML5 app on the brand new top-of-the-line phones and be satisfied by how slick your app works. But many of your users bought free or cheap Android phones with sub-par processors and you would be horrified with how your apps run on these phones. See for yourself: go to your local wireless carrier and buy their cheapest subsidized phone. Install your app and see how it runs. My bet – it’ll crash within minutes…
If you’re already investing in native iOS and Java developers, why not go the distance and develop true native applications?
At raw engineering, we believe true native is the best way to approach mobile development. As Tedd Fox of Salesforce says, HTML5 is a great way to “get your product in the mobile door [but] [i]t is not and should never be your real product strategy!” By developing natively in Objective C and Java, you can achieve all the cool UI functionality without spending weeks optimizing your code. You can develop the functionality yourself or use a bunch of awesome open source components (we’ve open sourced Twitter’s StackScrollView and Scroller on GitHub).
The development process is simplified significantly when you’re working in a native only environment. If you’re developing for iOS, you only have one developer tool to use and support. There are also automate unit testing abilities for iOS and Android to ensure that your apps are working flawlessly.
The Facebook Fiasco
Facebook had a fantastic native application. Unfortunately, they got sold on the promise of HTML to quickly develop and iterate hybrid applications with significant cross-platform code sharing. When Facebook switched to building hybrid applications, the biggest issue was speed. You remember that first time you launched Facebook on your iPhone or Android and suddenly, you had to wait… even when you were on WiFi.
This was the day I stopped liking the Facebook application. Waiting for my content is one thing, but waiting for my content to render is a completely different story. By making this change, Facebook pissed off millions of its users off. Since then, Facebook spend a billion dollars on Instagram to get mobile users and has returned to its native roots.
The promise of low cost and available resources for HTML5 is forcing people to make the wrong decision in the short term that would impact their long term success. Today, HTML5 is not the right solution, but maybe in a couple years HTML5 and mobile devices will catch up to native performance and usability. Go native and you will achieve the functionality you are looking for with lot less iterations and headaches and most importantly, a satisfied user base.
At raw engineering, we’ve built several apps using all the approaches above and we strongly recommend going pure native. I just don’t see any cost savings for the HTML5 approach. Even if someone argues that you get 10% – 20% saving, is it really worth it for an inferior application?
Check out this awesome infographic to help put things in perspective: