Why the FT Loves the Web

I joined the FT late last year, a couple of months after the launch of our web app, and since then I've been working on getting myself a nickname: Chris ‘App Killer Smith. It's not because I'm having a negative effect on the web app, at least I hope not. It's because I've been working to shut down legacy products which have been replaced by it.

You may have seen the stories about the final closure of the old iOS native app recently, and before that we also quietly retired our Blackberry news reader which had done a decade's service. I'm wielding the axe. Others will follow.

These closures demonstrate the extent to which the FT's mobile and emerging platforms strategy is predicated on our ability to deploy the web app across multiple platforms and browsers, and underline again what a bold move the FT's web app launch was.

At the time, some commentators suggested it may spark a rush of media organisations out of app stores, to sidestep third-party terms imposed there. This stampede hasn't happened, but it's not because news organisations don't want the freedom to run their own payment solutions or decide their own terms.

Core offering
Rather, the best business case for a web app is one which assumes it must become the core offering across the major mobile platforms. Part of our thinking in having an app built purely on web technologies - HTML, CSS and Javascript - was that it could be deployed in a range of contexts, both directly in the browser and wrapped as a native app for inclusion in app stores, if we choose to.

But if you've already got a million downloads of your existing iPhone, iPad and Android apps, other offerings in play on the challenger platforms, revenue streams running from them, advertising models in place... it's tough to make the decision that they must all be replaced.

It’s not easy to migrate a million customers to a new product. You may have large teams working on them, and plans around them stretching far into the future. Besides that, HTML5 is still an evolving standard; creating and maintaining excellent user experiences with it across multiple platforms, screen sizes, browsers and device types comes with its own set of challenges.

Safari renders HTML differently from Chrome, which in turn is different from Internet Explorer, and so on. Databases are different; touch interactions and offline storage are handled differently by different operating systems; app platform owners have different levels of design compliance for native functionality, allow different levels of reach into the device, and so on.

Maintaining one codebase for all screen sizes from 3.5-inch up to widescreen 10-inch in this context is tricky, to say the least – unexpected formatting glitches during development are par for the course. We're lucky enough to have an awesomely talented team of HTML5 developers and testers working on new functionality and platforms, but there are still problems which take time, plenty of head scratching, and lots of hard work, to resolve.

But it's worth it to have the pleasant problem, as we now do, of looking across the landscape of browsers and platforms and saying: "Which one shall we go for now?" Here's an FT prediction: there will be more new launches than sunsets this year, without any doubt.

Heavy lifting
I'm working on just such a project for the FT right now. (I don't only do hatchet jobs.) It's our Windows 8 preview app. Just as we did when we launched on Android, we're using the core web app at the heart of this new launch, and wrapping it up to run beautifully on the Windows 8 platform. There was some heavy lifting to do in porting aspects of the code for IE, rather than Webkit browsers, but we're there now, and the web app helps us to take full advantage of opportunities like this.

So what is the future for HTML5? Will web apps have their day? I believe they will. As we've shown, the decision to launch one doesn't mean all other mobile offerings must be switched off at once. Media owners can stagger their launches to new platforms to fit with the commercial needs.

Despite the complexity, the goal of "code once, deploy everywhere" is getting closer, and does make commercial sense. It's not here yet, but browsers increasingly support the same standards. As new device APIs open up to browser-based applications, the software to support touch interactions in the browser improves, and good practice in responsive design becomes better-established, the case for staying native-only gets weaker and weaker.

Chris Smith is product manager - emerging platforms, at FT.com