What exactly is an app?

In 2007 when Apple launched the first iPhone, the future looked rosy indeed for the mobile web. Suddenly we had a mobile platform that we could see gaining mass market traction (and this time without kidding ourselves). But a scant 12 months later apps arrived, and the tide turned.

The problem for the web was that apps were simply so much easier to use. Only having to worry about one size of screen and one style of interaction, an app was easier to build and offered the kind of graceful user experience that guaranteed happy customers. For publishers, apps were also instantly familiar as a packaged format for content – offering the prospect of a return to a print-era premise of publishers as both originators and packagers of content. Publishers had struggled to let go of packaging, finding it hard to make money from individual pieces of content that can be easily copied, shared and disseminated via social media.

As well as being outgunned on the user experience and packaging fronts, the web was also left with a terminology problem. The ‘app’ as defined by Apple was a package of Objective C code and assets, distributed via a proprietary app store, installed in whole on the device before use. But web developers had already been building apps for years – a different definition to be sure, but the same term. It’s hard to argue that eBay.com isn’t an application, for example.

But eBay.com and other desktop sites like it, accessed through a mobile browser on a smartphone, steadfastly refuse the label of ‘app’. What I find particularly interesting is that most people who use the term to describe the tools on their phone probably don’t have the technical knowledge to understand the underlying technology or distribution model of any particular tool. So the identification of something as an app is not, in fact, anything to do with what technologies it uses.

Instead, it’s in the experience. The simple truth is that an app is anything that ‘feels like’ an app. And those app-like qualities are:

  • Perfectly filling the screen
  • An interface designed for touch
  • No ‘browser-like’ elements or page loading behaviour
  • Gesture interaction
  • An icon on the homescreen

Some of these are quite trivial, but two are really important: how the interface lays out on the screen, and whether it is designed for touch. Without either of these, you don’t have an app. The Boston Globe, thanks to its widely respected elegant responsive design, will always fit the device you’re using perfectly. But the pages, with their conventional hover-and-click hyperlinks and page reloads on each navigation action, don’t cut the mustard. It’s not an app. Similarly, an interface designed for touch is part way to being an app but if you have to pan and zoom to see all of it, to your users it’s not an app.

Which brings us to the FT web app then. The FT app IS designed to fit the screen, has a touch optimised UI, gestures, no page reloads, and you can save an icon to the homescreen. For all its lack of native code, it’s still an app.

This concept of apps as design ideals is not limited to touch either. One of my favourite websites, BBC Good Food, has an alternative site which it markets as its Chrome web app. Using the Chrome app system allows a site to get deeper access into the browser, but other than that, it’s entirely up to the developer to decide what the site looks like. In general, they decide that when building a Chrome app, it should look totally different to their regular website – with far less extraneous content, using more of the space on the screen and scaling automatically.

Since all these attributes are good things from a user experience perspective, you could argue that ‘appifying’ a website is in fact simply an exercise in making a better website. But consider that in aspiring to some of the benefits of native apps, websites can overlook some of the stuff that they already do better than native, and thereby become poorer websites in their attempts to be good apps.

For example, web pages have URLs, making it easy to reference any web page from any other, one of the founding principles of the web. Often ‘app’ sites offer all their functionality through a single URL, or try to hedge it with fragment navigation (the FT app is currently guilty of this, something we hope to fix soon).

There are alternative views of what apps are as well. The idea of separating the do-stuff sites (such as eBay, Amazon, Gmail etc) from the get-stuff sites (including the FT) is one such idea, but I don’t buy it, personally (and not just because we’re in the latter category).

So we call the FT web app an app partly because it implements those user experience features that users associate with ‘apps’, and partly because it’s undeniable that large scale digital news operations like ours are based on complex software and are therefore defacto ‘applications’ anyway.

To be perfectly honest though, I’d rather just call it the FT.