Mobile apps and HTML5 are two of the hottest technologies right now, and there’s plenty of overlap. Web apps run in mobile browsers and can also be re-packaged as native apps on the various mobile platforms. With the wide range of platforms to support, combined with the sheer power of mobile browsers, developers are turning to HTML5 as a “write one, run many” solution. But is it really viable? There are still compelling reasons to go native, and clearly, many developers are indeed going that route.
- We can divide mobile functionality into two dimensions: the experience of the app itself, and the way it hooks into the device’s ecosystem, e.g. for Android, this would be features like widgets and notifications. In terms of app experience, native apps can do more.
-
It’s true that many in-app features are simply beyond reach for an HTML5 app. No matter how hot your web skills are, if your app is stuck in a sandbox with no camera API, it won’t be taking snaps anytime soon! Making a hybrid – native plus web – app is hardly an ideal solution. It adds complexity and applies only to web apps wrapped as native apps, rather than traditional websites accessed from a mobile browser. But it mightn’t be necessary for long. Web standards are evolving rapidly, and modern mobile browsers are keeping pace. Offline storage, geolocation, canvas graphics, and video/audio playback all enjoy widespread support among modern smarpthones, for example. Even camera is starting to be supported — as of Android 3.1, it’s possible to capture photos and videos using web standards. And the latest iOS browser supports WebSocket for 2-way streaming, as well as device orientation detection.
Overall, mobile is evolving. But the web is also evolving, and fast. Among desktop browsers alone, there are five major browser vendors evolving standards and adding features at lightning pace. While it’s not a trivial process to port these features to mobile, many of them have already made their way into the mobile browsers.
Native is a fast-moving target, but the web is closing the gap. -
Native apps use robust programming languages (e.g. Java, Objective C, C++) which were designed for complex application development and have a proven track record. The APIs were designed ground-up to support the platform at hand. You can easily debug apps in desktop emulators which provide a close representation of the target device.
What makes web development particularly troublesome is the huge diversity of browsers and runtimes. When your app runs, it’s no guarantee feature X will be available. And even if it is, how will the browser implement it? Standards are open to interpretation. On the other hand Web is often easier to develop, especially if targeting multiple devices. -
One of the defining features of any platform is its look and feel. Users come to expect controls to be presented consistently and manipulated in the same way. There are certain idioms which vary from platform to platform, e.g. what happens when the user performs a “long hold” (keep touching an element for several seconds)? Platforms have standard idioms for such things, and you can’t satisfy them all with a single HTML5 app.
Furthermore, platform look-and-feel is orchestrated by the platform’s native software library, whose widgets encapsulate the kind of look and feel users expect. You get a lot of the expected look-and-feel “for free” just by using the native toolkit. -
App distribution mechanisms, like Android’s Market and Apple’s App Store, have been overwhelmingly popular in recent years and are a major driving force for the entire mobile industry. Any developer can submit their native app to the marketplace, where users can discover it through a combination of browsing, searching, and getting recommendations. Not only that, but if you’ve done your job right, the glowing ratings and comments will convince users to hit the all-important install button.
It would be nice to declare a winner here, but right now, there is no clear winner. Some apps are best suited for native and some are best suited for the web. The web stack arguably has more momentum, but in terms of capabilities and execution qualities, native apps are moving fast too. And unless there comes a time when web technologies are a first-class citizen on the majority of mobile OSs, native will always be an important consideration.
There’s a 3rd option here. That’s using natively wrapped HTML5 or hybrid apps. One particular cross OS solution is PhoneGap. This also provides access to phone functions such as the camera API and is independent of the OS too.
One thing to mention about HTML5 is that it may have slower performance than a pure native solution, so for example a highly graphical games may be difficult get to work well in HTML5 currently. Although it should be noted that if you natively wrap HTML5 on an iPhone you get a multi-fold performance increase over ordinary browser running.
Another evolving tool is Sencha. Keep watch on it.
An HTML5 application created in an online browser might mean that you simply will eliminate flash whenever making web content.All wonderful things ought to return to a conclusion,
What about the 4th option of using a tool like Appcelerator to create native apps using Javascript (leverage your current talents to create native apps). Thoughts on that?
What technology you choose to build your mobile apps should be influenced by what your app does.
1. Will your app need to run without requiring access to the internet?
2. Does it need to access to many or specific OS/device APIs and sensors?
3. Is app performance and battery efficiency important to your end-users?
4. Do you want to create user interactions that are designed for the device platform?
Not all apps have these requirements, but if “yes” is the answer to most of these questions, then you may want to avoid HTML5-based solutions.
Also, you probably would like one code-base that runs on multiple platforms, thus minimizing development, maintenance and operation efforts. Well designed apps will separate the app business logic and database layers from the interface layer, thereby allowing as much code as possible to be in common across platforms while also enabling device-centric user experiences.
One other problem that developers who have used HTML5 approaches often cite as a big problem, and why so many of them abandon HTML5 approaches, is the very poor debugging and testing environments they offer.
There are alternatives to HTML5 coding – and another benefit is they don’t require hard to find and expensive programming expertise.
Enterprises are seeing more of their information consumed by customers from mobile devices than while sitting at a desk — that is, it’s become a “mobile-first” world. This is causing a tidal-wave of mobile app development.
Enterprise want to leverage what they have already: 1) their staff who already understand their business processes and back-end systems; 2) the skills and dev-tooling they already use. They want to maintain their sophisticated programming capabilities, to create fast-running apps that don’t drain down battery power.
So, for the next few years, we can expect a lot of churn in the tools adopted by to create mobile apps. A lot of tooling used to create 1st and 2nd generation apps is *already* being abandoned as developers encounter limitations and learn of more efficient solutions to create cross-platform mobile applications.
Hi Dave,
Really liked your comment. Specially the deciding factors between native and HTML5 based platform. Will keep these points in mind in near future !
Hi,
Thank you four your nice writing on HTML5 vs. Native Mobile App Development
Thanks.
great! looking for these type of explaination
I’ve done some work for a mobile marketing company here in St. Louis, and all we focused on was HTML5. Non-native app development is cost effective, and works almost the same as native apps. For businesses looking to dip into mobile app development, I highly recommend looking into HTML5.