Today we’re talking about hybrid publishing apps from the technical perspective.

Let me start by quoting @brad_frost from his article "Native vs. Web" is Total Bullshit:

No one working in the mobile web will say that the web can out-perform native. We simply don’t have the tools available to even try. Likewise, no native app developer is going to say their app is available to anyone with an Internet connection. Now that we have "the argument" out of the way, let’s ask the question: how do we approach mobile?

Touché. So let’s look at the different components that need to be built, and for each of these decide whether native technologies or web technologies will make our life easier. If you have no idea what I’m talking about, you’ve probably missed the earlier articles in this series -- Part I (target platforms), Part II (data formats) and Part III (native and web). Maybe read those first and come back here.

Native Tech vs Web Tech: Component Death Match

For the rest of you, it’s time to dive into the detail. For each of the main components of a publishing application, we’ll look at the two options and decide which we think is better. For those that couldn’t be bothered, jump straight to the table at the end.

Publishing for Tablets_Flavors1.png

Financial Times and OnSwipe: Pure Web Apps

Content Layout

What: The ability to display and format content in a way that will keep editorial teams happy.
Summary: Writing a layout engine is difficult. However, HTML and CSS are made for this, and improving all the time. WebKit is available almost everywhere. Other layout engines are painful and, more importantly, device specific. While it is, of course, possible to write layouts using technology like iOS Core Text, it is more effort, requires hard-to-find skills and means an app update for every new layout. We went into detail here in Part II (data formats).
Verdict: Web wins hands down.

Core User Interface and Navigation

What: A beautiful user experience that delights the user and just feels right.
Summary: Even if you ignore the consistency user experience arguments, it is difficult to make a pure web based interface that has the smoothness and performance of a completely hardware accelerated native user interface.
Verdict: Native takes this one, although the web will make a strong comeback in the coming years.

Business Logic

What: The code that sits behind the user interface and controls how the application works.
Summary: For applications without much business logic, this isn’t really relevant. I’d argue it is probably easier to implement the business logic natively, but that does mean it needs to be done in different languages for different platforms. Writing the business logic once in JavaScript is an interesting (albeit new) idea (Kirin) so I’m giving the Web a slight edge here.
Verdict: A controversial narrow victory for the Web. I’m probably going to regret this.

Access to device features

What: The ability to access hardware and software features of a tablet or phone.
Summary: The web can’t compete here yet. Yes, yes, I know the standards are on their way, but it is going to be a while. PhoneGap is the King of the Hybrid when it comes to this category. Have a look at their documentation for a complete list of features that Native can do that the Web cannot: Accelerometer Camera , Compass, Network Connection Info, Contacts from Address Book, Device File System, Geo-location, Media record and playback and more.
Verdict: No contest. Native wins by a country mile.

Publishing for Tablets_Flavors2.png

The Times of London: Pure Native

Content Downloading

What: The ability to download content to the device so it can be read quickly and easily.
Summary: Both web and native can download content just fine, and both use the same protocols to do this. Native has a slight edge in that it is easier to download a single zip package and unzip it on the client, although it has to be said that Javascript only unzip libraries are appearing. However, the clincher here is the ability to automatically download content in the background -- iOS 5 Newsstand being the neatest implementation of this. I can wake up in the morning, get onto a train with no connectivity, and read my daily paper which was silently downloaded overnight. The web can’t match this yet.
Verdict: Native, because remembering to download in advance is a pain in the ass.

Offline storage

What: The ability to store content on the device for offline consumption.
Summary: HTML5 can support offline storage in a number of ways, and there are some pretty good apps out there that utilize it. However, there are two problems here. Firstly, the amount of space you can use is somewhat limited. On iOS, you initially only get 5MB. You can increase this to up to 50MB, but only with a rather unpleasant dialog that confuses many users. For an constantly updating newspaper, 50MB should be plenty to store the latest edition. However, for a rich, editioned magazine with full page interstitial adverts, 50MB just isn’t enough.
Verdict: Native, because pretty magazines are big.

Learning Opportunities


What: They ability to notify the end user of important events, for example breaking news or a new edition of content.
Summary: Unless your users constantly have your browser tab open, and you have some AJAX polling going on from your web application, web technologies currently don't support this. Your best bet is to notify users by sending them an email or some other out-of-band information. Both Android and iOS have rich, native push notification systems that provide a much more seamless user experience that provides instant gratification.
Verdict: Native, because we like to know things in real time.

Online and Offline Analytics

What: The ability to track how users interact with your application.
Summary: The web mastered online analytics many moons ago. The problem is, offline analytics are much more difficult as one needs to record actions that are taken offline, store them on the client, and reply the actions when returning online. This is of course possible, but it requires a fair bit of effort and in many cases it isn’t possible to tell the server the exact time an event occurred. However, if you have a native app you can find libraries from the big players (for example Adobe Omniture or Flurry) that make all of this easy.
Verdict: Native, but only just as the web will catch up soon.

Online and Offline Advertising

What: The ability to retrieve ads from an ad server, and display them while online and offline.
Summary: Advertising is difficult. Fetching the right amount of inventory for offline display is difficult. Placing it dynamically inside your app is difficult. Keeping the assets small is difficult. However, it is of course possible, and every ad server that matters serves their ads as HTML. So this is an easy victory for web technologies.
Verdict: The web, because HTML is the only advertising format that makes sense.

Social Sharing

What: The ability to share your interactions with the app with the world, and for them to easily join in if they want to.
Summary: Virtually every app (native and web) provide the ability to share something on the two big networks -- FaceBook and Twitter. The sharing is easy. The hard part is sharing something that lets the recipient back into the application. This is possible to do in native apps, but it is clunky and involves the user opening a link on the correct device, with the application pre-installed. Protocols are being worked on to improve this for native apps, but they ain’t here yet. URLs are the stuff the web is made off, so this all just works in the web app.
Verdict: No contest. Apps are closed. The Web is open. Web wins.

The Summary

Publishing for Tablets_Flavors_summary.png

So there you have it. According to the table above, there are still quite a few things that, from the technical perspective, are best done natively. As time passes and web standards progress, expect the web to catch up in all of these areas. But this is going to take many years so, in my humble opinion, hybrid apps are the way forward the foreseeable future.

Till next time, in which we will talk about the different ways we can package and download content, and compare edition based content with permanently updating content.

Editor's Note: You may also be interested in reading: