BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
There's much debate between the development of Web/HTLML5 versus native applications. How much of this is vendor-driven? What are the best uses for each?
A few years ago, a co-worker and I decided to drop a couple of apps on Apple's app store. It wasn't just that "everyone was doing it" (which they were); it seemed like a good way to explore a nascent platform that showed the potential to become the next big thing. Even though Tan Timer and Your Personal Dance Tutor didn't become runaway financial successes, they did accomplish their other purpose: They helped me learn about the nuances of building for the iOS platform.
More recently, the rise of HTML5 support in mobile browsers has left developers scratching their heads again, wondering:
- What's the best way to build my mobile app?
- Is one approach more productive than another?
- How will my choice affect end users' experiences?
Let's take a step back for one second and clarify why we are focusing on the mobile space. Isn't HTML5 support also prevalent on desktop browsers? The answer is that it depends.
Developing with HTML5
If you visit html5test.com, you can see how desktop and mobile browsers stack up. Even though Chrome currently has the desktop lead and great HTML5 capabilities, Firefox and Internet Explorer (IE) can't be ignored. Sadly, IE, with its particularly deep enterprise footprint, trails the pack. In the mobile space, however, we don't see this issue. The two most popular platforms, Android and iOS, offer far better support for this new set of standards, making mobile the safer bet.
In keeping with my previous efforts to learn more about the developing native applications by working on two iOS apps, I decided to try my hand at HTML5. My biggest question was: Could the final product rival what I had done with native code?
I decided to use the jQuery Mobile framework. The core jQuery library is hugely popular, and I hoped my existing experience with it would give me a leg up with jQuery Mobile. What I quickly discovered is that most of the questions I encountered online regarding jQuery Mobile focused on what are essentially nonissues with the development of native applications. Common questions include:
- "How do I hide the browser address bar?"
- "How can I add my app to the phone's home screen?"
- "How can I access the phone's camera?"
Even though I could get close to what I wanted, the additional research, work, and testing convinced me native still had its advantages. With that, however, comes the disadvantage of having to code for multiple platforms. Drat! Why can't there ever be a clear winner?
Benefits of native applications
For the app I was building (imagine a sort of supercharged closet organizer) and the experience I wanted to convey, HTML5 and jQuery Mobile weren't a good fit. I have to acknowledge that I have seen other apps with different functionality where native didn't offer any discernible advantage.
With HTML5, any person can navigate to your site and experience your app.
There is also the nontechnical but very important issue of monetization. If you go native, you can target app stores like Apple's as a revenue source. Then, you've locked yourself into a sometimes arbitrary-seeming application review process. Even if you're approved, you can be summarily yanked from the App Store later.
With HTML5, any person can navigate to your site and experience your app. However, your monetization options are primarily limited to subscription fees and ads. Further, on a technical note, the experience of adding links to an HTML5 site is simply not as user-friendly as going through the App Store and installing a native application. Your HTML5 app is arguably less discoverable since you will have to rely on discovery via the Web -- an obviously much larger place to stand out from.
Finally, as I bounced between environments, I noticed an interesting difference in how user interface and user experience are emphasized. In HTML5 frameworks, a core objective of user interface (UI) capabilities is focused on mimicking the standard touch and screen-flow capabilities of native apps. In the native space, however, there is more focus on new gesture mechanisms for navigating content. Perhaps that's another reason HTML5 currently seems to me like a better option for more traditional interactions driven by sites, but native seems to work better on more innovative UIs.
Inside the mobile development arena
Although there are a lot of vendors offering tools in the native and HTML5 space, perhaps the one refreshing observation I can make is that there is a surprising lack of marketing disinformation in spite of all the competition. The fact is that neither approach is currently the perfect development option for all application developers.
The mobile space is only getting larger, and everyone seems to realize there is plenty of room for multiple development techniques. The key for today's developers is to understand which approach best fits the task at hand. Are you hoping to differentiate your product with cool new UI features and you need high performance? Native is probably your answer. Do you already have a popular site that receives high traffic and you want to support multiple mobile platforms using a single code base? HTML5 is a good choice.
This story isn't finished though. With the continued growth of mobile, we will undoubtedly see additional tools and frameworks emerge. Developers that become skilled in multiple methods will ultimately give themselves and their clients a rich set of options to choose from.
Michael Ogrinz (@mogrinz) is the author of Mashup Patterns: Designs and Examples for the Modern Enterprise. He is also principal architect for global markets at one of the world's largest financial institutions.