Native App vs. Web App; Why Hong Kong Mostly Gets It Wrong.
- Jul 2012
- General
- Web Design
In Hong Kong, there are many examples where a popular website or business decides to release an app. In this sense, ‘app’ is short-hand for a native application; a downloadable thing that creates an icon on your homescreen, be it on an Apple mobile device (iPhone, iPad, and iTouch), or on an Android, BlackBerry, Nokia, or Windows device.
But there is another type of ‘app’. It’s called a web application, or web-app for short. In this context it usually refers to a website that, one way or another, works well on mobile devices. And it’s usually the better option.
Forgive me Hong Kong, but we are generally a little backward when it comes to this sort of thing. Let me reveal a little secret: most websites do not need a native app. Let me explain.
There are some things for which native apps are perfect. Words With Friends is a good example. As are WhatsApp, Facebook, Evernote, Skype. These services leverage the devices’ functionality in a way that the built-in web browser cannot.
But in Hong Kong apps are popping up all over the place that just don’t make sense. IFC has an app. Openrice has an app. Broadway Cinemas has an app. There is an app for checking ferry times. The Hong Kong Observatory has an app. Here’s why they might reconsider this approach:
Cost of development and maintenance
In all of these examples, a website went online before the app. So, in developing an app, the business is committed to developing a new platform and then maintaining multiple platforms. One for web browsers, and one for each device platform supported. This is an expensive proposition, both when the content needs to change, and also when a device maker releases a new product. Also, every change to an Apple app requires re-submitting for review, and the user to update. It slows down the process.
With increasing hardware fragmentation there will be new players and – like with the device-agnostic Android platform – more and more popular devices that need to be supported.
Web-apps avoid many of these pitfalls, as all mobile devices have in-built web browsers that follow almost exactly the same specifications. This is the beauty of open-standards as opposed to multiple proprietary, closed systems.
Being found on Native Apps vs. Web apps
There are millions of types of specific content that people want to get at. Often it is for a ‘single-serving’ purpose; the address of a shop or business, a schedule for the occasional movie-outing, a trip to Peng Chau, the likelihood of a typhoon 8 signal in the morning. It is inherent in the architecture of the web that this content is most easily accessed via a website. Web apps download the latest version of the app in a single visit to a URL. And most will be surfaced very easily by a web search via Google.
In contrast, apps are much harder to surface. They do not have a URL. They require multiple steps to download and engage with. The content is also harder to share. You can’t link to the content of an app’s page on Facebook or Twitter.
There are half a million apps on the Apple store. But for each category the ‘top-free’ and ‘top-paid’ lists are top-25s. And these are primarily made up of already successful apps. It is important not to under-estimate the marketing efforts required to get your app noticed. To make people aware of an app requires targeted advertising, primarily on… a website. Wouldn’t be easier if the content just loaded at this stage?
As the mobile space matures, people will increasingly demand immediacy. People will get bored of the novelty of looking for single-serving apps in the App Store. Let Google do the grunt-work of returning relevant results for people’s needs.
User Metrics
Traffic reporting and user-behaviour analysis is easier on websites, at least for the time being. Even with options to track behaviour on apps, there is no data on in-bound linking (since you can’t), and if a company also has a website they will need web-analytics too.
In-App purchase restrictions
Apple takes 30% of any subscriptions or in-app purchases of content, and bans links to external web-based payment options. It also results the publisher losing control of their user-data. This is why the Financial Times pulled their iPad app in favour of an HTML5 based web-app. For anyone wishing to sell subscriptions with decent profit margins, a web-app is a better option.
Ah yes, but what about additional functionality?
It’s true that for some purposes, a native app is better. Games especially perform better when they are optimised for individual devices. Apps can take advantage of all sorts of functionality, such as GPS, cameras, accelerometers. But for the examples given these are beyond the requirements of the service. And as web-standards evolve, the browser will be able to leverage most of these things. In some business models, the ability to easily charge US$0.99 for access makes it a no-brainer. But all the example apps are free.
In the cases above, the business could build a website that works on all devices, and users could bookmark these to their homescreen if they intend to revisit regularly.
So, why aren’t people doing it?
Mobile content delivery is a young and fast-evolving space. People are testing the waters with different approaches, as we would expect of dynamic companies. But I believe that there is just a lack of awareness of the possibilities of web-apps.
Responsive web design enables websites to adjust their presentation according to the device. But few websites are doing this yet. This means that when people visit websites on their phones, they are frustrated by having to zoom-in and scroll along two axes to complete tasks. Apps are custom-made for small screens, so they seem immediately more appropriate. This is not an inherent limitation of website design; it is a legacy issue of websites that were coded before this form-factor was even considered.
However, in the case of a number of Hong Kong companies, I’m afraid they may be guilty of jumping on the app bandwagon, or worse, taking an ‘ain’t-broke-don’t-fix-it’ approach to their established sites and starting afresh with a native app to avoid the growing pains of completely ovehauling their web offering.
We believe that a web-app approach would serve all of these companies better. Initial and ongoing development costs would be reduced. Content production workflow would be simplified. Traffic analysis would be simplified. Users would get an improved and more consistent experience from re-designed websites. Users could share your content easily via email, blogs, or any social media, boosting in-bound link juice. And the natural search engine advantage that they already enjoy would mean more engagement with the improved services.
Of course, we’d be happy to help.
For more around this subject, here are some great articles:
http://mobithinking.com/native-or-web-app
http://econsultancy.com/us/blog/7832-the-fight-gets-technical-mobile-apps-vs-mobile-sites