Publishing for Tablets: Going Native?

By Jon Marks (@McBoof) Sep 21, 2011

So where were we? In the first article of this series, What You Need To Know About iOS and Android, we decided that the wise publisher currently targets iOS first and Android second. In a second article, Data Formats for Fixed and Flowable Content, we agreed that HTML is the sensible way to expose a publisher’s content to the world. Today we’ll talk about how we take this content and create wonderful tablet apps.

For the rest of this article, we’ll look at the available options and think about them from a business and the user-experience perspective. We’ll also touch on the technology, but next month we’ll devote the entire article to this part (of course — I’m a geek). First, some terminology.

Web Apps, Native Apps and Hybrids

For the purposes of this article, I’m not going to worry about the distinction between a website and a web app. Both of these are written entirely using HTML, CSS and Javascript, the languages of the web. And both of these live only in the browser, which provides a (mostly) standard platform regardless of the modern browser the user chooses to use. Web apps are normally discovered using a web search. I’d recommend reading Of Sites and Apps by @jamespearce to properly understand the distinction between websites and apps.

Unlike websites and apps, a native app runs on an operating system (be it iOS, Android, Windows, etc.). All operating systems are different and have their own programming language (Objective-C for iOS, Java for Android, etc.). These apps are normally discovered and purchased in App Stores controlled by a vendor.

A hybrid app is a native app that is created using a combination of the operating system language and the languages of the web. They still run on the host operating system and live in the App Stores. In my humble opinion, a typical user should not be able to tell the difference between a native app and good hybrid app — it is a purely technical distinction.

(From Future of Mobile by James Pearce)

Remember that our smart publishers want their content to be output at HTML. Writing some native code once isn’t necessarily a problem. Changing the production process every week/month to output content in multiple proprietary formats can get really expensive. So the choice is black and white — do I create a web app or a hybrid app?

The Business Argument

If you ignore the technology completely for a second, are there any fundamental differences between a native app and a web app? At the moment, I’d like to highlight three of them — how users discover and use the apps, how you make money from the apps, and how much consumer data you gather. The first is important for all apps that want exposure and usage, or to be monetized through advertising. The second is important for any publisher trying to sell their content. And the third is important for analytics and increasing the value of subscribers.

Love it or hate it, at the moment users spend more time in apps than on the mobile web. The chart below, from a report from analytics firm Flurry, shows how things have changed in the last year. A recent Nielsen survey found Android users spend twice as long with apps. The mobile web is definitely the destination of choice if the user doesn’t know exactly what they want, and it normally starts with a Google search. However, if the user knows what they want (for example, playing a game or reading YOUR magazine), they’d go to an app given the choice. At the moment, most users find native apps easier.