One of the advantages of my role is that I get to do entrepreneurial things in a large company – which can be frustrating sometimes – but I get to see a broad perspective on many things related to web content delivery.
A quick disclaimer – I am not technical (whatever that means), but I have been heavily involved in mobile – both managing the development of mobile apps and looking at the surrounding ecosystem and trends.
I want to both summarize and extend some of the current thinking – to crystallize some important advantages to web apps from a practical product development perspective. I ignore the implication for processes such as marketing and operations, and focus more on technology selection in going web vs. native and some immediate considerations/implications.
The advantages boil down to a faster time to market and a reduced cost to market, as well as reduced ongoing product development costs.
The first thing to say is that web apps are essentially web sites optimized for the mobile phone. Because of this – they run in the web browser on the device. All of the good mobile browsers would run websites in a similar way (note exceptions described later).
Web apps have several advantages over native apps:
- Allow cross-platform/device product development – basically means you build once and it works on all mobile devices (not quite true…see later) – for two main reasons:
- Web apps are essentially websites – which means that mobile browsers that are capable of handling HTML/CSS/Javascript should be able to run them. Native apps are dedicated code, which means that they are platform specific. So between device classes (e.g. tablets of similar size, smartphones of a similar size) the app should be okay.
- Web apps allow element re-use across device classes – which basically means that you can, to some extent, re-use user interface (UI) elements (e.g. lists) that you used for an iPad app in your iPhone app – more easily than when building native apps – especially across platforms (e.g. between Android and iOS).
Obviously this is the real world, so things aren’t as rosy as this. There are several main sources of constraints to scaling in the way described above:
- Limited access to device specific features – before web apps had very limited access to device specific functions (e.g. GPU, accelerometer, gyroscope) – however this is changing.
- Different rendering by different browsers – at the fringes of these web standards, the way each browser renders them might differ – so need to accommodate multiple browsers.
- Differing screen sizes on each device – different devices have different screen size so the UI (and UX, IA) of a product may need to be adjusted.
- Different user expectations – the user expectations for the look and feel for the app may differ across devices (e.g. buttons on the Android with differ to those on Symbian) – but these expectations may converge at some point.
- Quirky frameworks – means that things don’t quite work the way they look on the front cover and are still maturing – but these are being ironed out as I write.
- Improve templating for similar portfolio products – an example is as follows – say you have a portfolio of 50 journals and each journal needs a separate app, for whatever reason (e.g. branding or the customer bases are sufficiently different because of the topics).With a native approach – you would have 50 separate code bases. Potentially more if you start to scale across multiple operating systems.With a web app approach – you can reuse common elements and ‘pull in’ the customizations as required (e.g. different splash screen, branding, search bar).
[Quick aside – the key dimensions of ‘scaling’ implied by the above are (1) browsers in a specific device class across the operating systems/devices (e.g. tablets of similar screen proportions/sizes – iPad/Safari and Xoom/Browser) (2) browsers across device classes (e.g. iPad to iPhone or to HTC) (3) products of a similar nature in a product portfolio (e.g. books, journals) – these dimensions drive the constraints mentioned for both native and web app approaches].
- Reduce ongoing maintenance costs – because of the above you don’t have to maintain separate code-bases and develop them independently. Especially if you are serving multiple platforms. As an aside – you also don’t need to go through any app store approval processes to introduce and iterate the app.
- Use existing organizational competencies – currently, many firms have no/limited in-house capability to build native apps on any scale and will hire vendors to do this. For various reasons I wont go into, this approach can be problematic.Web apps are websites and can reuse the existing web development competencies in the organization (there is some ramp up time for getting used to any frameworks e.g. Sencha Touch, jQuery mobile but most good web developers that I have worked with pick these up quite quickly).
- Take advantage of improving browser capabilities and standards – browser capabilities will continue to improve as well as the specs of the standards, which they support.
Some of the disadvantages of web apps is that they (a) can’t be distributed via app stores (they are websites after all…) (b) don’t support large amounts of offline storage (but this is improving) (c) they can’t (yet) be used to deliver the next generation of Call of Duty… The first two points can be circumvented by using a hybrid approach, which essentially involves to things:
- A web component – written in HTML/CSS/Javascript – defines the UI and the app features that are used by the user. Usually built using a framework such as Sencha Touch, dojox.mobile, jQuery Mobile. These frameworks all have different feels to them and differ in their maturity.
- A wrapper (native component) – a native part written to be platform specific – this gives the web component access to device specific services that a pure web app couldn’t get to (e.g. increased storage, GPU access). An example of a hybrid app is Flipboard. Wrappers include PhoneGap (mainly an IBM do – check out the contributors, also funnily enough so is dojox.mobile…) and Appcelerator.
Tactically – hybrid apps can be used as a stepping-stone into the pure web app space as browser capabilities and standards continue to improve/evolve. There is a point at which its just worth t building a native app, if the wrapper becomes too complicated.
The above ignores some of the big technology elephants when talking about mobile (or desktop in general) – such as web analytics competence, open APIs, security and cloud to name but a few. These are the main things that drive cost and time to market in mobile – as well as determining your ability to do anything with any products that you build – e.g. capture value (!).
I have also ignores some of the commercial and operational aspects of doing this – including marketing, team composition and competencies, business models etc.
I will try to cover some of these in a later post if there is interest – so let me know.
Hope that this was helpful.
Related links:
