Mobile Apps Native or Web?

A planning guide for Mobile Marketing and Development Teams

by Bill French, Founder, iPadCTO 2nd Edition
Copyright (c) 2010 - Bill French http://bfrench.info - http://ipadcto.com

Mobile Apps: Native or Web? The Landscape The Inuence of HTML5 Hypothesis Show Me The Money Visibility Interoperability Off-line Web Apps Device Specic APIs User Interface Hybrid App Wrappers Top-of-Mind and Brand Visibility Native vs Web Planning Framework
Copyright 2010 by Bill French Cover design by Bill French Book design by Apple All rights reserved. http://bfrench.info * http://twitter.com/bfrench No part of this book may be reproduced in any form or by any electronic or mechanical means including information storage and retrieval systems, without permission in writing from the author. The only exception is by a reviewer, who may quote short excerpts in a review. Printed in the United States of America First Printing: April 2010 Second Printing: August 2010

4 5 6 7 7 8 8 9 9 9 10 11 11

Preface

Mobile Apps: Native or Web?

You probably have a plan to build a mobile app, but youve struggled with the basic question should I build it using open web standards such as HTML, CSS, and javascript, or should I build it s a native app for the devices I want to target? This is a difcult question and one that requires considerable thought and analysis. To help you wade through the pros and cons, Ive created this comprehensive list of issues and provided a pros-cons template to quickly begin to quantify your requirements. At the outset, it is important to say that this is not a debate about which approach, native or web, should win in the marketplace. Rather, it is far more sensible to debate the how positive and negative attributes of a particular development strategy will unfold in the context of a specic business requirement. As such, this e-book will focus on an objective to rst establish a context, and then apply sensible and rational arguments, either for or against web or native apps. Youll nd these additional resources helpful. Three Tips for Creating a Native App 2011 Mobile Enterprise Development Controversy: Native App versus Web App Native vs. Web vs. Hybrid: Mobile Development Choices

Chapter 1

The Landscape
By 2012, for every iDevice in circulation, at least 3 Android-based devices are likely to be glued to corporate users ears or serving up business apps at a blinding adoption rate. On deck for CXOs next - how do we support these devices? How do we manage the multiple form-factors, different keyboard features, and a variety of displays? This is not an easy challenge if your organization is likely to support just two of the many mobile platform choices. It gets very complicated and hyper-dimensioned as soon as you add a third platform or just one platform with multiple device form-factors. First, a few observations about the mobile app development landscape. Developers have generally embraced the iPhone with exuberance. Developers [typically] want to develop stuff for the iPhone. This is to Apples advantage; a strong third-party developers that can make or break a mobile platform. Apple is creating animosity among developers with its nutty App Store policies; the app store can make or break an app. Unfortunately, if developers want to develop for the iPhone platform, they must go to the app store for distribution. Many of the issues cited above, are not present in other mobile platforms. It may come as a surprise to many, but Apple's original plan for iPhone development was to use web technologies, and web technologies only. This idea came not only as a surprise to journalists, but Mac developers and web developers by and large, do not expect this move. The app store was created in response to a lackluster community support from developers. Before this, Steve Jobs, ordered his developers to create Web applications with Web standards, but that did little to compel the community to get behind the idea of building everything in HTML.

It is very likely that Apple is working on its own CSS-centric Web OS for mobile devices, and possibly for the desktop as well. But this philosophical approach to mobile app development has been slowed, if not suppress by all of the effort and energy devoted to the app store. The recent release of iPad, simply puts off the inevitable; Apple will eventually provide a CSS-centric Web OS.

Chapter 2

The Inuence of HTML5

While very powerful HTML standards are emerging that will aid in the development of quality mobile touch web applications with outstanding user experiences and high performance characteristics, theres still some work to be done. But even in its earliest debut, HTML5 is rapidly being adopted by Microsoft, Google and Mozilla Foundation. Google is so excited about HTML5 its ushering it in as A New Era of Mobile Apps. NextStop(.com) is an example of an HTML5 mobile touch site that works seamless across mobile hardware and OS platforms. As it turns out, the MPEG Licensing Authority recently announced that it will indenitely extend royalty-free Internet broadcasting licensing of its H.264 video codec to end users, erasing a key advantage of Google's WebM rival and cementing Apple's preferred H.264 as the video format for modern HTML5 video on the web. As reported by Apple Insider, While anyone can license H.264 under non-discriminatory terms, free software advocates have condemned the use of commercially licensed video codecs on the grounds that it forces web content into a form that requires licensing fees to play back (or alternatively requires the use of non-licensed code and the legal quandary that involves). Apple has pressured the MPEG LA to keep licensing affordable in the past, originally holding up support for MPEG-4 in QuickTime until the authority agreed to reasonable licensing terms. A combination of pressure from Apple and the competitive threat from Google's WebM likely prompted the group to ofcially agree not to impose any future licensing restrictions on the free web applications of H.264.

Indeed, these are scary times - industry giants each poised with their ngers on the launch button, but cooler heads are likely to prevail. Google continues to support the iOS-compatible H. 264 video playback in YouTube because any change in support for H.264 would be unwise since demand for H.264 video from mobile devices that can't currently support either Flash or WebM continues to rise rapidly. Support for H.264 extends well beyond Apple's iOS products, and includes nearly all existing mobile devices and likely all future smart mobile devices planned for the foreseeable future.

Chapter 3

Hypothesis
If we think about native apps versus web apps, and we believe is a reasonable expectation that almost anything could be developed using HTML and open web standards, one hypothesis that serves as a good starting point is that with a few exceptions, most native apps could be written as web apps and provide a relatively similar experience. While this hypothesis is probably true, the category of exceptions may be large and rife with devils in the details. Even with relatively signicant advances in HTML 5, the bigger elephant in the room are app developers who have a general disdain for mobile web apps, and users who have generally high expectations in terms of user interface and performance. As your strategy emerges, be mindful of the elephant.

Chapter 4

Show Me The Money

At the very pinnacle of this issue is the topic of payment. Mobile app payments are a very complicated subject. Apple's app store offers an easy and convenient way of making money with third party apps. Mobile operators have the greatest inuence when it comes to e-commerce transactions, because they are already billing everyone, and they are able to identify unique users because of embedded SIM cards.

Apple's in-app payment solution brings an element of streamlined efciency to the app development framework. It is one less thing that application developers have to worry about. Imagine building all of the payment-related services in open web standards - thats a lot of work. Certainly there are third-party companies that will lend a hand such as PayPal, and perhaps Google Checkout. However, for the most part, needed to app developers can reduce the heavy lifting, while web app developers must provide all of this functionality.

Chapter 5

Visibility
A key issue with mobile app development centers on the ability to gain visibility for an application. Native iPhone and Android apps have an advantage, because the app stores, themselves, take on the responsibility of providing a sick visibility and awareness. Apps with high demand may be featured, and apps with low demand, but high prot margins may also gain advantages for greater visibility.

Chapter 6

Interoperability
Of all the issues surrounding the debate of native versus web for mobile apps, interoperability is the biggest. And while this is a single element in the worksheet that accompanies this guide, it is a very weighted issue. Software applications success sometimes pivots on the ability of the enterprise to create code bases that are interoperable across multiple platforms. Interoperability is typically trumped by the user interface in the long run, hence the growth in native app development. In the short run, we become extremely excited about native apps, their performance, and the ability to deliver seamless installation and high-value experiences. Coupled with easy payment solutions and lack of device APIs, web apps are hamstrung from the beginning.

Chapter 7

Off-line Web Apps

To the issue of off-line web apps, it is entirely possible to design a web app that runs in off-line mode on Safari for iPhone and other Web Kit browsers. In this regard, native versus web is a draw.

Chapter 8

Device Specic APIs

Device-specic APIs that provide access, especially at the le system level, to device functionality such as the address book, calendar, the camera, and other hardware specic features, are coming for web apps. However, they are still not available to the extent that makes it possible to do some of the things that you can do today with native apps. One of the more important features of mobile devices is generally available from the browser geo-location.

Chapter 9

User Interface
Second only to interoperability is the user interface. This is fundamentally at the heart of the entire decision-making process concerning native versus web. When it comes to games, it is almost a certainty that you will have to resort to native app development to be competitive. But the question remains, should we give up interoperability for user interface issues in every case?

The challenges with user interface issues in web apps is no different than the challenges the web faced in the mid-90s. Everywhere you looked, developers were building executable applications that were installed only to desktop computers. With the emergence of the Internet, and eventually the World Wide Web, businesses were faced with the reality that eventually their customer facing, and employee facing applications would need to operate as efciently on the Web as they presently did on desktops. That said, there is no doubt in my mind that eventually, web infrastructures for mobile computing will reach a point where user interfaces will be equally satisfying in web apps.

Chapter 10

Hybrid App Wrappers

The concept of using a native app wrapper around your web app, makes it possible for you to build a very lightweight native app that frames your web app. This is been done successfully by a number of companies who are keen to create an environment with interoperability, while also gaining visibility in app stores. This approach allows your development team to learn and master only the basic aspects of each native platform. Once you perfect a native app wrapper for any given mobile platform, you do not need to update it unless the device API or OS changes. The only drawback to this approach relates to off-line storage; the WebView control in the iPhone OS does not support off-line caching available in Web Kit browsers.

Chapter 11

Top-of-Mind and Brand Visibility

One of the reasons that companies build mobile apps is to create more top-of-mind brand awareness for its users. Native apps provide distinct brand awareness that is almost inescapable. Every time your customer returns on their phone, there is your brand, staring back at them as an icon on the phone (or iPad) desktop. Seemingly, this is not possible with web apps. However, there are clever things that developers can do to encourage users to establish direct links to web apps on the desktop with an icon that is functionally identical to a native app.

Chapter 12

Native vs Web Planning Framework

The accompanying native versus Web planning framework spreadsheet is very simple. To use it, select the importance and degree of difculty for each of the requirements listed in the rst column. Each of these columns, provides a pick list including values from none to high. As you select these items bear in mind that these are thumbnail values intended to gauge some level of quantied, but I use reecting how important each requirement is to your overall mobile app project. When you have nished doing this, the scores for native and Web will appear at the top. The highest score for either native or web, indicates the likely direction your mobile app project should take.

I am pretty sure Ive missed a few important requirements in this framework. Consider this version 0.2 and future versions will likely be more polished than potentially more comprehensive. However, feel free to change the methodology of the sheet and the requirements -- there is no rocket science here, just logical thinking in terms of requirements and relative strengths of each approach.