Lately there seems to be massive hyperbole on the battle between native mobile applications and Mobile HTML5. It seems that just about every day there’s a new article about how HTML5 will rule the world and make mobile apps a thing of the past (see “HTML5 will replace native apps, says W3C boss“). On the other hand, there’s the other side that says this all a load of baloney, extolling the benefits of native apps and the myth of HTML5 (see Ben Sandofsky’s blog post “Shell Apps and Silver Bullets“)
Telenav has been in the mobile applications business since the Wild West days of 1999 – building arguably the most sophisticated applications on these platforms – from J2ME, Symbian, PalmOS and Blackberry Java in their heyday to the modern iOS and Android Ice Cream Sandwich platforms of today. To much fanfare, we also delivered “Scout for Apps” – the world’s first HTML5 browser voice-guided turn-by-turn navigation program that all runs within the browser, with no apps, no downloads (Sign up for our developer program or experience Scout for Apps free at Scout.me). It really takes sophistication of HTML5 Browser applications to the next level. Needless to say, we know native apps AND we know HTML5.
The simple answer is this: The world needs BOTH.
The time is now to take advantage of the many capabilities of HTML5. However, there will be times when you need the power and access of the native platform. Anyone who will say any different is probably going to sell you some snake oil next.
Now before you think that this is a cop out, there are situations where you can get away with HTML5 only or native only, but that is really just limiting your opportunities. Once you get over the fact that using one doesn’t necessarily means the death of the other, you’ll stop wasting time debating and start focusing on building an app that your customers love
Mobile Web and Native Apps: Access for Everyone, Anytime, Anywhere.
First off, there is a great deal of confusion in this discussion around mobile Web sites built with HTML5, native Apps with HTML5 Views and pure native apps. Let’s try to address this first:
- Mobile Web built with HTML5: This perspective is about not having mobile phone apps at all – simply using your web browser on your phone to give functionality to all. Some may call these “Mobile Web Apps” where the mobile site performs the same functions as a full-blown application.
- Native Apps with HTML5 Views: Modern mobile platforms allow developers to create WebViews inside of a native application. These WebViews allow developers to use the plumbing and capabilities that come for free with Web Browsers in addition to access to native functionality.
- Native Apps: Applications that are developed in the mobile platform’s SDK – Objective-C for iOS and Java for Android. These are the traditional applications developed for mobile devices.
I won’t delve too far into the debate between mobile Web and applications, but I would say that with statistics showing that 50% of mobile use is from mobile browser, having a mobile website that is useable in a mobile Web browser is invaluable. If your application has facets that aim at delivering content designed to be consumed while on the go, this is doubly true. With a little investment in SEO (Search Engine Optimization), you can generate tremendous amounts of traffic to your site – even on mobile. The last thing you want to do is put up a lame experience for those users or force them through a download process. That is when your users will hit the back button and hit the next link.
At the same time, building a native app enables you to promote your application through the Apple AppStore or GooglePlay (formerly Android Marketplace) and monetize your application easily through paid applications or in-app purchases. Moreover, having your native app on the device is like a constant reminder to the user to engage with the application, leading to much higher engagement with your users. These opportunities are invaluable and should not be ignored.
Your product needs BOTH application and mobile web presence – end of story.
Fully Native Applications vs. HTML5 WebView Applications
The real war being waged is around the development of fully native applications vs. applications that create HTML5 Webview containers through which all logic is implemented.
Famously, many major applications have moved from completely writing native applications to writing the vast majority of the application in HTML5 WebViews in a native container. LinkedIn has doubled-down on their iPhone, Android and iPad apps running a huge amount of HTML5 (see articles here and here). Facebook and Zynga are both huge proponents and betting big on the possibilities that WebViews bring to the table.
Here at Telenav, we build GPS navigation software and quite frankly, it’s pretty complex stuff. While everyone knows about how GPS is able to find you with pinpoint accuracy, the GPS chips used on most phones have purposely limited capabilities to conserve battery life and to make your smart phones as compact as possible. It means that there is sophisticated technology we’ve built to perform things such as “snapping” your position onto a roadway or adjusting the voice guidance based on your speed and heading or detect when you’re off course to provide corrections to your route. In the meantime, we’ve got our OpenGL engine running rendering your route, traffic, your animated vehicle and playing voices. Oh, and did we say we can play all of your music from your iTunes library?
For a very long time, we were building our applications entirely in Native code – C++ and Java were the main development languages on the J2ME, Symbian, PalmOS, BREW/BMP platforms. We had built up a large team of mobile developers that knew the ins and outs of all the different platforms, what the different tricks were to keep the network connections running smooth, how to characterize different GPS chip implementations etc. The UI/UX experience was simple due to the small screens, low memory, lack of GPUs and slow networks. You played with the hand you were dealt and life was good.
However, as the phones continued to evolve in capabilities, the demand for increased sophistication started to bubble up. Sophisticated 3D maps, voice recognition, mobile commerce, high resolution screens, social network integration all started to become elements that needed to be developed. At the same time, additional improvements to the core features were required as well, such as navigation out-of-coverage, accelerometer integration for better positioning, traffic optimization were being added in parallel. To top it off we had to juggle all of the new platform requirements – platform style guides, Apple Certification requirements; the amount of elements that needed to be juggled to ship an application became unwieldy.
One of the key things that we did at Telenav was to create a clean separation between the UX and the underlying application logic. By providing a clean separation we were able to have the flexibility to leverage platform-specific UI elements if so desired as well as manage the various platform UI idiosyncrasies. When it became possible to leverage HTML5 WebViews in mobile platforms, it became obvious that we could benefit from this. We have been shipping HTML5 WebViews in our applications for over a year now and plan to continue to expand on this.
At this point, many might ask what the advantages are to shipping with HTML5 WebViews. I want to share a few:
1. Continuous Release: Some developers have pointed out that “saving a few days on app certification” is not worth the cost of the limitations of HTML5. Much of this view comes from an environment where you have an application that is all built within a single team. Once you get to multiple teams trying to coordinate, the challenges become much more apparent. Facebook famously does daily releases – and it is able to do so because of the way they are able to decouple end-to-end features from each other and release with confidence. Use of HTML5 is a key enabler of this capability, having a clean separation even within the UI allows independent control without requiring a complete build and side-effects are limited. Teams can work independently on their features that can be rolled out “when they are ready” as opposed to waiting for some big “stop-the-world synchronization”. We know what happens when we put too many synchronized blocks into a program – sluggish performance and worse yet, deadlock!
2. HTML5 is faster and easier to develop: The reality is that building a HTML5 WebView is almost always faster and easier. While there are many nuances, tips and tricks to building great HTML5 experiences, it is trivial to build many experiences in HTML5 without any prior experience. Yes, there are situations where creating complex Javascript can be challenging to the uninitiated, and there are things you don’t really want to do in Javascript either. However, we’ve built the Scout for Apps program where our entire navigation engine, audio player and UX controls are built in Javascript and HTML5. I would not recommend that everyone attempt to port their applications entirely the HTML5 without the right kind of experience with HTML5. Don’t try to enter a bike race and expect to win if you’ve never ridden a bike before.
Finally, many apps have primary use cases of simply finding and displaying content – these are ideal applications for making extensive use of HTML5 – because this is what the original Web technology use cases were to begin with. Using WebViews you get all of the standard HTTP and HTML functions handled for you as part of the framework whether it be resource caching, event and error handling or connection management – these are all things that you can take advantage of without writing a single line of code.
3. A/B Testing: One of the most interesting things that happens when using HTML5, is the fact that we are now able to empower our UX and Product teams to make changes to the UX flows to test various scenarios that resonate best with users. The ability to modify HTML5 pages means that the team can validate a UI or feature change without requiring a change in release. This enables a incremental rollout of a feature change which can be scaled up or rolled back based on user behavior. It allows us to change incrementally with confidence.
Hybrid Applications – Native and WebViews Together
I have up until now been extolling the virtues of the HTML5 WebView, but the reality is that there are many things that are still needed from the native platform. This is not all thrown out of the window. Some examples of things that we will continue to get from the native platform:
- Access to phonebook, making calls, accessing camera, audio player playlist etc.
- High performance graphics – OpenGL, Specialized Screen Transitions (Yes, WebGL is interesting but not standard enough. Canvas is nice, but not yet high-performance enough on a broad set of mobile devices)
To all my mobile native developer brethren, don’t worry, your job is safe for quite some time yet.
The Rolls-Royce solution is ultimately the Hybrid mobile application, one that is written with a native application container that can have HTML5 WebViews displayed but also with a mix of native application for certain critical pages.
Here at Telenav, since mobile is our bread-and-butter, we have built our applications cross-platform on this Hybrid idea. Our application is a native container built on top of a core application SDK written in C++ (not Objective-C or Java) that is completely cross-platform (we’ve produced functional builds for iOS, Android, Windows Mobile, QNX etc.). With the UX layer separation that I alluded to earlier, we are able to opportunistically leverage HTML5 within our application. This is built by leveraging PhoneGap and providing additional JS-Native capabilities to access native objects from our HTML5 WebView. We have a number of use cases built within our application that leverage HTML5 extensively to great success. Our experience with this has made us confident in further investing in expanding this approach in the future.
Conclusion
All these battles between native mobile apps and mobile HTML5 is a load of hooey. As application developers, designers and product managers, we need to ultimately focus on what delivers the right value to the end-user. At the end of the day, users don’t care what technology it runs on, just that it gives them what they want and delights them by giving them something they didn’t even know they wanted.
Everyone should plan to have BOTH a mobile Website and a smartphone application – you can’t afford to ignore either. When building a smartphone application, you can choose pure native or pure HTML5, but there will be trade-offs on both – the complexity of your application may ultimately shift the thinking either way. However, for the greatest flexibility, the Hybrid approach is the best way – taking advantage of the best of both worlds. Leverage HTML5 for what it was built for, displaying content in an effective way that adapts dynamically to the data changes. Leverage native for what it does best, to provide a fast, efficient implementation for key parts of your framework.
Make Great Experiences, Not War!
Cheers,
Shannph
Chief Scout Architect
Scout is all about helping people make daily decisions about where to go, what to do, and how to get there when they’re on the go – and wherever they go: on their computers, phones, or cars. Today, we’re making it easy for them to get Scout within their favorite location-based websites and apps: yours. Introducing Scout for Apps: the worlds-first, HTML5 browser-based, voice-guided navigation service for developers like you that helps you increase user engagement and create new revenue streams.
navigation with just a click. Other apps may give your user a map or even directions, but Scout for Apps provides a premium experience with instant turn-by-turn voice guidance without having to download or install anything – and it’s free for your users. One click of the Scout “Drive” button launches a seamless session either in a browser or directly within your app.
FOLLOW US