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.

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.

Now to the money. If you have a native app, Apple currently demands 30% of your revenue when you sell (both subscriptions and one-off) via their store. And they have strict, frequently changing rules about how you can promote external sales channels (Android take less, but to be frank I don’t think any publisher is making any money in an Android marketplace). If you have a web app, you can completely avoid this 30% Apple tax, sell whatever you want, however the hell you want to sell it. The Financial Times have done this, and have produced what I think is probably the best example of a newspaper web app to date.

But you’re not the Financial Times. I’d argue for 95% of all publications, you want to be in the App Store. Hopefully you already have most of your loyal subscribers in a database already and grant them access as part of their existing subscription -- Apple have no issues with this. And as the user conversion difference between one-click App Store purchases and do-it-yourself payment forms is ridiculously big, you’re far better off getting 70% of the revenue from a large number of new subscribers than 100% of very little indeed. So unless you’re pretty confident you can target most of the iPad-wielding readers in other ways, grit your teeth, go with the flow, and try to get your new readers through the App Store with a (native) hybrid app.

Lastly, I’ll touch briefly on the consumer data ownership front. The battle between Apple and publishers is still raging here, and Apple appear to be giving a bit of ground. But all of this could change at any moment, so assume for now you’ll never get data from the people that bought your product through the App Store. I’d say the argument above holds too -- it’s better to have no data than no subscriber.

The User Experience Argument

Users dig consistency. At least I do. When I am using my browser, there are interaction patterns that I know and love. I get spooked when something in my browser behaves differently to everything else in my browser. However, there are some things I don’t expect to be consistent. I expect every website to use different colors and fonts on their navigation, for buttons to be different shapes and for animating elements to be unique to every site.

When I’m using a native app, things are different. I want all the buttons to be the same shape and use a consistent set of icons across apps. I am used to the acceleration and momentum of the native controls when swiping, and anything different feels a little bit … wrong.

So if you’re building a web app, should you try to make it feel native? I think the tweet below from Javascript guru @thomasfuchs summarizes my thoughts best:

This is where I start to doubt the utility of mobile web apps that install themselves on a user’s home screen with an icon, and use idioms that are based on a specific operating system. As an example, a huge amount of work has gone into JavaScript touch libraries that try to behave exactly like iOS. The whole point of a pure mobile web app is to run on all platforms. A web app that pretends to be an iOS app would feel wrong on Android, and the same goes the other way.

Based on the above, I’d say you have two choices. Create something that either feels completely natural in the browser, or something that feels completely natural on the host operating system. Don’t get stuck in the middle.

Go Native!

I think that, mainly for business reasons, every publisher except those with a very healthy long-term subscriber base (think Financial Times or WSJ) should be in the App Store. I also believe the content should be rendered as HTML. So this means building a hybrid app. I really like the way @jamespearce describes these in his recent Future of Mobile presentation -- it isn’t about Apps vs The Web. It’s about Apps Built With Web Technology.

But there are different levels of hybrid. On the one extreme, the entire application could be written using web languages and turned into a native application using a project such as the excellent PhoneGap. Or, for technical or UX reasons, you might decide to write more of the application natively.

In either case, building these things are hard. So we want to be very sure we’re building the right thing. To get an idea of just how hard building one of these properly is, have a look at this wonderful architecture diagram, created by @fling. For a larger image and more details, I urge you to read his excellent Anatomy of a HTML5 Mobile App.

Although this diagram reflects a web app, it is the same order of complexity to build a native app or a hybrid. Next month we’ll dig into the technology and levels of “hybridness,” and highlight the parts that can give even the hardiest souls a headache.

About the Author

Jon has spent the last two years deeply involved with tablets. In 2010, he lead all architecture and development work for NewsCorp's multi-channel publishing initiative, Project Alesia. Jon has recently co-founded a new company, Kaldor Group, which specializes in tablet publishing and advertising.