Web apps vs native apps: the lowdown for publishers

The release this month of the Amazon Kindle web reader has reignited the debate as to whether publishers should be putting their limited R&D budgets into creating native or web applications. Broadly speaking native apps are delivered through app stores and web apps are delivered via the devices web browser. There are different merits to each approach, and no clear water between the two. The one thing that is clear however is the gap between native and web apps is starting to blur: from a user's point of view they can offer the same functionality and each can provide an exceptional user experience in their own way.

In this article I will give you a primer of what’s available on each platform along with some of the pros, cons and upcoming developments. We’ll start with a quick overview of each platform.

Native applications are those that are created using technology specifically tied to and developed for a device, usually lower level programming languages. For example developers will use Objective-C, C++ for the iPhone apps and Java for Android and Blackberry devices. These applications run as compiled code. This means that they are optimised for the devices on which they are designed to run, this reduces power consumption (very important for battery powered mobile devices), allows developers to make specific use of graphics and audio capabilities, enables multi threading (doing more than one thing at a time) etc, etc.

Web apps don’t benefit from this. Javascript is the powerhouse behind web apps and is an interpreted language, this means that it is run via an intermediary program (simplistically the browser) and is not optimised in the way compiled code is so does not yet run as fast although there have been many recent advances in Javascript performance (Google’s V8 interpreter for example). This is important as developers never have enough memory, network speed or CPU power, especially on resource restricted mobile devices and it makes web apps less efficient at performing some processor intensive tasks such as animation (this is why the web version of Angry Birds works on your PC but not on your mobile device), and also why there are very few mobile games created as web applications. (That said there is emerging technology designed to address this on the horizon, known as WebGL).

Vendors have also invested heavily to increase developer productivity through their various developer kits (collections of pre-written code for common tasks). These do a lot of the heavy lifting required to create native applications. For example, with the limited amount of screen space on a mobile device, a simple form often turns into multiple views whose state needs to be managed by the application. Apple developed Cocoa Touch specifically to deal with this situation. Additionally, through these vendor provided development kits native applications can be well integrated into the capabilities provided by devices outside of the browser such as the user’s contacts, their photos, background processes, access to the iPhone gyroscope etc. At the moment web apps are sandboxed inside the web browser and may only access the device through a fairly restrictive number of Javascript calls that vary device by device for example only recently have web apps been able to determine the user’s current location from the device GPS.

Another area where native apps currently have a lead is that native apps are able to provide a consistent user experience with other apps on the device. For example vendors provide tools to aid localisation and they provide developers with the means to utilise standard buttons and input mechanics that web app developers cannot, this is why web apps often do not “feel right” when users interact with them even though they offer similar functionality. A good example of this is the spring back that the iPhone offers users when they scroll to the end of a list. Until the next release of iOS this is not possible and has to be hacked through the use of some quite complex Javascript with the end result still not feeling quite right. This highlightes the absolute importance of the UI and user experience.

So from the above it would seem that web apps are second rate to their native counterparts. Not necessarily so. Web applications are created using a common set of standard technologies; HTML, CSS and Javascript. The “standard” part of the previous sentence is important as this is where the real benefit of web apps lies. All the major device manufactures have chosen to base their web browsers on the open source Webkit rendering engine - except for Microsoft, which characteristically has clung to IE as its rendering engine for their Windows Phone 7 operating system. This means that web applications can be deployed to multiple devices with little modification, if any (the user interface concerns discussed above notwithstanding). They can display launch screens have icons on the users dashboard all like their device specific counterparts. Additionally they can take advantage of the benefits brought by the new HTML5 spec such as local storage, caching, CSS animation, Video and the drawing canvas plus much more. In addition device manufacturers are exposing more and more phone capabilities to Javascript (through vendor specific calls), for example GPS positioning data, orientation etc.

ROI is an important consideration for publishers and in terms of audience and distribution, web apps benefit from being app store agnostic. Sales may be made from anywhere on the web, location independent and updates can be made available centrally and pushed to all devices without the need to go through sometimes lengthy App Store review processes.  This allows publishers to be nimble reacting quickly to user feedback and analytics insight. This brings us onto the final topic I wanted to discuss - App Stores.
Native applications have the benefit of vendor investment in distribution and marketing through their various App Stores. No one can deny the attractive offer of these stores - in Apple’s case 100 million iPhone users ready to buy with a single click in an environment where customers expect (albeit for small amounts) to pay for content. They hold their credit card details and they make the process as frictionless as possible. However, App stores are by their very nature busy places and discovery is a problem with sales affected disproportionally by standings in top 10 lists and vendor promotion (the effects of being promoted on the iTunes homepage are well publicised). SEO is difficult as is off store PR. Currently, there are no web stores for web apps (although Google is making first steps) but they can be distributed, marketed and tracked in the same way as a standard website and would be leveraging expertise developed already by publishers in the development of their web properties. It has been claimed however that there is also a legacy carried over from the web in that customers expect web for free. This is something that publishers must overcome by driving real value through the web apps that they produce, enhancing functionality through phone features and device context.

Finally, to complicate things a little more - there is also a middle route. Applications such as PhoneGap allow web app developers to create their software and them wrap them in a native application wrapper: this allows them access to phone specific features and submission into the various application stores. HTML and CSS are optimised for layout and many developers of native applications use HTML and CSS behind the scenes to help create their interfaces and then embed this content into their applications using webviews - effectively displaying web pages within their applications. In fact, the Apple iBook application is an example of this.

So what are publishers to do? It depends on the specific application that is to be created. Going back to the catalyst for this article Amazon’s new web reader one can see that this is an ideal candidate for a web application model. It is content rich and this content can be well handled by HTML and CSS (which is optimised for delivering well typeset content), there is limited animation, local storage requirements are modest and easily secured and sandboxed by using the HTML5 local storage capability. The reader itself is static in nature allowing it to be easily cached to the local device, again using HTML5’s enhanced caching capability. It is backed by the impressive Amazon Kindle infrastructure, updated centrally and has it’s own payment/store functionality not needing any vendor specific infrastructure. Finally, Amazon is marketing the application heavily and using the technology itself as a PR opportunity.

There is no reason why this model could not be expanded to include a richer content experience such as CSS animation, graphics and sound, again as device capabilities improve and new standards emerge the inclusion of 3D or game content via WebGL is a given. Some may argue that the web reader version of the Kindle may cannibalise the Kindle hardware market but this is a shrewd move by Amazon in that it puts the real value of the Kindle (the content) into the hands of as many readers as possible and allows them to sell their product in whatever way they wish (cutting out the iTunes store saves them Apple’s 30% cut on each transaction for example).

So what’s the verdict? Without a doubt we will see an increase in the number of apps developed using web technologies in the coming months. This is an excellent opportunity for publishers. Many of which are already investing in HTML and CSS skills for the production of their ePub titles (as consumed by Kindle, iBooks and other e-book readers). It makes sense to utilise this new knowledge and leverage web applications and emerging HTML5 elements such as the canvas to enable innovative, DRM protected content (protecting publishers’ rights in all but the most extreme circumstances).

The document based nature of HTML web apps also means a good fit with existing workflows used in content production. Clever tagging of content and meta data use could easily enable efficient publishing workflows that embrace apps as a quick win channel instead of the sometimes costly exercise they are today. I see HTML web apps enabling publishers to get to market quickly, iterate and importantly fail fast without deep investment.

So to summarise, the lines are blurring, the future will definitely see a swing to more applications developed using web technologies driven by reduced development costs from the write once model, pressure on ROI, by the options for monetisation outside of the app store environment and the increased access to device features and browser performance. I’m looking forward to reviewing this article in 12 months from now.

One final note - despite the criticism leveled at Apple and the iTunes store, Apple is actually a great champion of the mobile web and mobile web applications and has shown a great vision for the technology. The company effectively gave mobile web app developers a year’s head start when they launched the iPhone initially announcing that all applications would be created for the phone using web technologies. A year later it released the developer tools to create native apps. With the upcoming release of iOS 5 Apple is also readying a slew of additions to mobile Safari that will reinforce this commitment to mobile web apps (remember the spring screen issue above). Conversely this week has also seen the demise of the HP WebOS (formally Palm WebOS). I’m very sad to see this go and hope that someone steps up to take it on and drive its development further.



DRM with canvas

How do you realize a DRM with the html5-element "canvas"?

Good coverage

Good, informed coverage of this endlessly debated subject.

I would add this however: Web Apps really only hold value for the publisher, not the end user. End users want top-tier, interface-consistant native apps which are tuned to their native device and operate seamlessly with it and its attached devices.

For the publisher, of course, HTML5 opens cost and time saving doors to cross-platform publishing and circumvents app store restrictions, royalties, and access to customers.

So, for those still seeking the answer to the debate, sorry, but it will continue to be a careful decision to be made on each and every project.

Post new comment

You will need to register to comment on Futurebook.net. Register here This will take less than a minute.
By posting on this website you agree to the Bookseller Comments Policy. comments go live immediately, please be relevant, brief and definitely not abusive.
Enter your FutureBook username.
Enter the password that accompanies your username.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <p> <b> <i> <strong> <br>
  • Lines and paragraphs break automatically.

More information about formatting options

Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.