You know what they say, if you want to start a flame war have an opinion on HTML5 vs Native mobile app development. I’m reopening this can of worms because the landscape has changed over the past 18 months and surprisingly business are starting to lean toward HTML for upcoming projects lately.
Let’s get this out of the way first, my opinion is that native is always going to be the best route where the actual user of the product is concerned. They’ll get the most enjoyable and refined experience possible via a native application built by a capable developer. Anyone who tells you different is working some sort of angle.
That’s not to say there aren’t valid business reasons to go HTML though. An HTML application is very attractive if you need to support many types of devices and platforms and you either don’t have the internal resources to develop and maintain native applications or you don’t have the budget to pay someone to do it for you. It’s also a tempting option to just reuse a responsive web application that may already exist and save yourself the headache of a new project.
For many companies, the application being device agnostic will trump the user experience and app quality every time. If this is an internal application it’s easy to get away with it too because the users are your employees and, well, they have no choice. Still, if you talk to the owners of the project, the people who will ultimately be using the application, they want native and they know why they want native more today than they did 2 years ago. Their desire for an improved UI/UX, better speed, and more advanced functionality will suffer at the hands of an IT mandated HTML5 or hybrid application.
As of late, the tools available to developers who need to build an application once and deploy everywhere have exploded. Frameworks like famo.us, Ionic, PhoneGap, Sencha Touch, Appcelerator, Xamarin, and others are reducing the grunt work and improving the overall quality of web based mobile applications dramatically. The use of a shortcut tool (as I call them) like Appcelerator is an OK way to get a bunch of apps out quickly from a single code base, but now you have a native Appcelerator app instead of a native iOS app. True you can build for multiple platforms from that code base but you still have to learn Appcelerator (or Sencha or PhoneGap or whatever, not picking on Appcelerator) specifically to get there. It’s not nothing and you’ll be unlikely to work in other shortcut platforms once you pick one up. On the positive side, when it comes to maintenance, you’ll make that change in one place and be able to rebuild all your platforms.
Xamarin The benefits to a build once, deploy everywhere platform are pretty obvious. What may not be obvious is the fact that you still need to manually submit and manage your applications and listings in the individual app stores separately. You also may need to wait for the tool to support the latest versions of each platforms OS. And perhaps most importantly, you’ll face limitations, inconsistencies, and bugs as your application becomes more complex. Poor memory management and app crashes, layout glitches, lack of 3rd party library support, and missing native capabilities are common complaints about essentially every short cut tool out there. Unless your app is pretty simple, the user experience is going to suffer.
You do always have the option of building your app purely in web technologies and either wrapping a WebView in a native app or directing the user to a URL to use it. Mobile browsers have matured to the point where their performance is excellent for JavaScript execution. They’ve also gained many helpful features and APIs focused on mobile like web databases, access to the camera, GPS, etc. Taking this approach will help to keep things consistent and reduce the reliance on another platform or tool, but it comes with its own challenges. Choosing a framework (if any) is tough – there are a lot of conflicting reports on quality. Building a snappy UI that responds well to touch is also a challenge. Handling the myriad of screen sizes the app will be faced with can result in a whole bunch of awkward or broken break points – and in the end, you’ll still be faced with significant app restrictions as opposed to native if the app complexity increases.
Native beats out every other option. It has none of the cons that the other options have and it produces the undisputed best application. Users have grown accustomed to having a quality native experience and have beaten down even the biggest companies (Facebook / LinkedIn) until they moved to native. Your company might not be Facebook, but your users/employees have certainly been spoiled by good applications. The one place that native can’t compete is in development cost and maintenance if the app is launched on multiple platforms. While the cost of a single native app may be equal or lower than a hybrid or HTML5 app, the incremental cost of rolling that app out to additional platforms and maintaining those separate code bases is much higher.
In most cases, the space where a non-native app makes sense is when you need the thing to perform on desktops and laptops as well as mobile devices and tablets. If you just want to support iOS and Android, it’s worth the added cost and effort to make two native applications in my experience. The tooling has improved and platforms like Xamarin that use native UI’s and share the common core logic are becoming increasingly more alluring, but for my money, I’m sticking with quality over quantity.