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.
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.
Recent blog posts
- Can we float more indie boats?
- Measure for measure: the Digital Census since 2009
- A chuffed market's Children's Conference: #PorterMeets Charlotte Eyre
- #FutureChat recap: Publishing innovation
- Night of the Social Media: #PorterMeets Jonathan Maberry
- Alta Editions' cookbook innovation recipe
- WhereWereYouThen.com: Mining the memories of Ken Follett's readers
- The FutureBook Innovation Awards are open for business
- #FutureChat recap: Torchin' for books data
- Reedsy: Bending into digital self-publishing
- ISBNs in the aggregate refer to titles
1 week 5 days ago
- A question about ISBNs
1 week 6 days ago
- Not impressed by a data collection argument
2 weeks 3 days ago
- Understanding the reality of bookstore inventories
2 weeks 4 days ago
- Thanks for the input
5 weeks 6 days ago
- In this case, compliance is expensive
5 weeks 6 days ago
- I totally agree with JA Konrath's 12 points
6 weeks 3 days ago
- Tone vs Substance
7 weeks 2 days ago
7 weeks 2 days ago
7 weeks 2 days ago
Tweets from @thefuturebook
TheFutureBook Thanks to all who participated in today's #FutureChat -- Recap next week! t.co/Mk9Tmlms25 @TheBookseller
TheFutureBook One hour to #FutureChat, this week on "opening up to indies": t.co/Mk9Tmlms25 - Join us at 4pBST / 11aET / 3pGMT @TheBookseller
TheFutureBook Come along for our #FutureChat today on "opening up to indies" 5pCEST / 4pBST / 3pGMT / 11aET 8aPT t.co/Mk9Tmlms25 @TheBookseller