Here s how to choose the right mobile app for you. There is no arguing with statistics. The future of the web is mobile. Tablet shipments are increasing exponentially and within two years consumer broadband connections through mobile in G20 countries are predicted to be more than four times those of fixed line connections, according to management consultants The Boston Consulting Group. We could quote plenty of similar research findings but the blindingly obviously conclusion is that any brand or organisation not thinking about how to deliver a satisfying user experience on mobile within the next six to 12 months will be losing out to those that have. The question brands should be asking is not do we go mobile?, but how do we go mobile?, for there are choices that need to be considered carefully. Initially there are two paths, mobile web or a mobile app. The answer to which way to go is to look carefully at your audience and ask how they find you and how they want to interact with you. There are solid reasons for each to be the preferred option. The focus here will be on mobile apps for the reason that people spend about seven times longer on apps than the mobile web, according to the Nielsen Smartphone Analytics report. The report mentioned above is limited to smartphones, and the same metric for tablets would be nothing like as high because the experience of viewing through a web browser is significantly better, but those stats still make a compelling case. So if you head down the app route, what are the options? Until recently there were just two, with native and HTML5 apps offering totally different ways of achieving your goal. However, in the last year or so a third option has emerged, offering a hybrid of HTML5 with a native wrapper. The audience needs and your business requirements may dictate which of these is best for you. So what are the differences, merits and limitations of these three options?
Native Apps These are specific to a device (e.g. the iphone) and the operating system (OS) that it s based on. Built using the operating system code and because of this they make best use of the device capabilities, such as the camera, compass and geo-locator because they access them directly from the operating system. They can only be downloaded via the relevant app stores. Generally, they deliver a richer and more satisfying user experience because native code is better able to access the features of the device and to render richer graphics. You also get full access to all of the features, including those that HTML5 cannot give you, such as icloud storage and Newsstand and the app works even when the user doesn t have network coverage (unless the content requires it). Native apps are also faster to render and load data and graphics, both at launch and when using gestures like scrolling, swiping and clicking. Monetisation is more straightforward than pure HTML5 because apps are distributed through the relevant app stores with all the transactional infrastructure and search mechanisms they offer. However, given that free apps take up a staggering percentage of all new app downloads you had better have a featurelimited free app available to whet the appetite of your potential audience. If security is an issue then native may be your choice as they are able to access the security /encryption features of the device more easily. Native apps are expensive to build due to the fact that good developers (certainly Apple ios developers) are in short supply and thus get paid handsomely. You ll also have to build a separate one for each operating system you want to be on (ios and Android will garner you roughly 86% of UK consumers, Microsoft 8% and increasing and RIM (Blackberry) 6% but declining). Bear in mind that apps for each operating system will require separate maintenance and support, and if you really are going to exploit the full features of the device this means deploying a new version to optimise each new version of the OS (as well as ensuring the old versions are not excluded). Apple has at least one new OS release each year and Android has multiple new versions. Support and maintenance of an app is expensive. Accessibility is also becoming a serious issue. There are now more than 28 iterations of Android across multiple manufacturers, making it a very painful experience creating a truly accessible app for Android. Having access to the myriad new features developed for each OS is one thing, but to exploit those new features means developing and updating the app, and that s going to cost you. Apps in the Apple App Store can take time to go live due to the newly rigorous scrutiny they are put under to ensure they use some of the features of the device.
You pay a percentage of the price of each app or in-app purchase for the privilege of distributing through the relevant app stores currently 30% for both Apple and Google. Hybrid Apps These are a relatively recent addition and touted by some as the answer to all the drawbacks of each system. They are written in HTML5, JavaScript and CSS and then wrapped in native containers. They are effectively written once (roughly 90% of the code can be reused) and the wrappers allow them to be deployed across multiple operating systems, although you ll have to do some work with each wrapper to ensure the functionality really works as expected and that it does so consistently across all desired versions of the OS. There are several developer frameworks within which to build these hybrids, these include PhoneGap (used here at Haymarket Network), Icenium and AppMobi. Right for you if money is tight but you still need to make use of the features of the device or develop across multiple (Apple, Android and Windows) operating systems. The BBC used this option for their Olympic app. Development cost is lower than native because HTML5 developers are much easier (and cheaper) to find. The cross-platform deployment costs are reduced because the wrapper technology means you really only have to build the base code once. There is some work required to get it working across each operating system but it s nothing like as complex or time consuming as a native app. You have good access to the features of the device and just like native, the app works when the user doesn t have network coverage (unless the items you are trying to access require it). Monetisation potential is the same as native apps as they are only available through the relevant app stores. Speed of development is faster than native apps and maintaining and supporting the app is simpler due to the fact that you have a single base code to work from. The user experience is not quite as good as native apps because even though they have a native wrapper they are not in true native code and therefore don t have quite the performance of native or the ability to fully leverage the features of the device. Some of the developer frameworks have some limitations in terms of what they can do. They usually consume more memory than native apps. Launches and updates have to be pushed through the app store systems and approval can take time.
Pure HTML5 Apps Built in HTML5, javascript and CSS with access derived via the web. Instead of downloading the app to your device you effectively add a bookmark by putting the app icon on your home screen. The much-praised Financial Times app is a great example. This has long been touted as the solution to the problem of OS and device fragmentation as its proponents claim it s a single code that is written once and can run on any device, irrespective of operating system. However, the write once, run anywhere mantra that HTML5 evangelists have been preaching has been challenged recently due to the sheer number of browser combinations and versions, which makes it almost impossible to ensure everyone has the same experience. Right for you if your content is mainly information that requires constant updating, such as the Financial Times app. Development costs are reduced due to easy access to HTML5 developers and the fact that the code only needs to be developed once (although accessibility issues are driving up development time). Updates can be made immediately and as often as you want as all you have to do is deploy the new code to your servers, rather than having to submit new versions to the app stores and wait for approval. Apple has started to reject apps that don t use the functionality of the device, so if your app is mainly content driven then this may be your best option to access Apple devices. You don t have to pay the app stores fees for any in-app purchases, which allows you to take 100% of the revenue (minus the card or PayPal transaction fee). There is, though, no ready-made purchase method, so you ll have to create your own. Without access to the app stores some observers claim that it will be harder for people to find your app unless you promote it aggressively. Having said that, there are now so many apps in Apple s App Store it s almost impossible to find anything that is not promoted, either by the owner or by Apple themselves. You ll have to build your own transactional mechanism as you won t be sitting in the app stores. Overall performance, launch speed and gesture speed is slower than in native apps. Not only are there multiple browsers but also multiple versions of those browsers, so creating a consistent user experience is becoming more difficult, plus not all browsers support the full range of HTML5 features so some key areas of your app may not work for some users.
User experience will be affected by the app s inability to really leverage the capabilities of the device and the OS. There can be vulnerability around security in terms of cached data. This can be encrypted in native apps but not in HTML5 apps. The HTML5 code standard is controlled by W3C, and due to the slow pace of delivering support for it from all the manufacturers it s next to impossible for it to keep up, therefore there will inevitably be many new features each year that HTML5 either cannot access or cannot keep up with. Because the app is server-side, not device-side you will need good 3G (or 4G) coverage for it to work. Summary All of this makes it difficult to make a decision, especially given the expense of initial development, and the potential cost of getting it wrong. The problem is that in many cases, the upsides have a downside, for example, native apps give you a huge range of exciting device features, but exploiting them has a high cost implication. So really you need to decide what is most important to you. We ve created the following matrix to help you make your decision. Native Hybrid Html 5 User experience Excellent Good OK Cost Medium Low Best content type Static, graphics, feature, All Regular updates e.g. news, forms Ease of regular updates Monetisation Performance Very Fast Fast Slow Security Low Access to all audiences Very Expensive Expensive Inexpensive Access to devise features All Almost all Limited Available in app stores Yes Yes No So if the speed and user experience is most important to you then go full native, if regular updates to your content and accessing the widest audience is most important go pure HTML5, if you need to balance many requirements maybe you should look at a hybrid solution.