Developer’s dilemma – Go native or go html5?

With smart phone penetration growing steadily across demographics, traditional web app developers are forced to expand into mobile to keep their edge. Very soon, a mobile presence will be a requirement for survival. But, why is there such frenzy about going native or going html and the most important question of all, why should anyone care?

As a developer or as an enterprise, you are committed to providing a reasonably good mobile experience to your users or employees. But at the same time, as a technologist or a business owner, you are constantly making decisions about cost/time and performance. So, this question is very pertinent in deciding the immediate mobile future of your app.

Native apps are undeniably far better than browser apps in terms of performance and usability. But the major downside is that, it is very platform specific, which makes it extremely time and resource consuming. HTML5 apps on the other hand don’t offer the best user experience, but it is fairly simple to roll-out because of its platform agnosticism. This list of comparison goes on. But let’s see, broadly, what separates the two.

Native App
More suited for enterprise applications where users/employees are looking at convenience and productivity than the ultimate user experience.Suited for consumer apps (because of its ability to offer rich media experience) where there is a chance of users abandoning usage because of inferior UI experience.

You can reuse existing design and code which makes it faster to implement.Cannot re-use web assets. But, this contributes to a rich experience for apps especially those that use accelerometer, GPS, camera and other capabilities.

Platform agnostic. Development and testing times are much lesser.Very platform specific. Though the same reason contributes to a much better user experience, the development and testing times are significantly higher.

Advertising hasn’t matured much in mobile web yet.Acts as a monetization channel, especially for consumer applications through in-app advertisements.

It is a just a channel for mobile access.Apart from offering the convenience of mobile access, it is a strong discovery and distribution channel.

In the entire debate, important business wisdom to be applied is this: A reasonably good solution in the immediate present is far more valuable than a perfect solution in the future. What it means is that, if an HTML5 app will offer you the ability to roll out a quick and dirty solution for your user’s mobile needs, do it first. You can build the perfect solution ( a native app) later.

With that basic decision in place, the question will be how to make that quick and dirty solution reasonably good. Here are some broad guidelines to help you if you are going ahead with an HTML5 app.

● Implement only those features that your users are likely to use from their phones. For example, if you have a help desk solution, you can prioritize features like opening, closing and assigning a ticket than an admin dashboard to create labels or filters.

● Re-use your design from the web app to give users the same experience across devices. They should not have to go through a learning curve to use your app on mobile

● If your web app offers the Ajax convenience, make sure you offer that in your mobile app too. The idea is to do absolute minimum set of features to make mobile useful but provide the best experience for those minimum features.

● Use your browser app as a prototype to study mobile usage patterns among your users. This will go a long way in getting the usability right for your native app

Let’s say you are into gaming, a browser app has much less relevance overall. In that case, here are some guidelines for building a quick prototype for a native app.

● Conduct a quick survey to find out the device preference of your users (between iPhone, Android and others). Build an app for that majority user base first.

● Push out a working solution fast enough with third party services like Phonegap instead of building entirely from scratch.

● If it works, repeat the same for other device platforms.

● Rinse, repeat your process to fine tune the user experience