One of the most interesting talks at OverTheAir was, for me, hearing Andrew Betts of Assanka talk about the work he and his company had done on the iPad web app for the Financial Times, app.ft.com.

It's an interesting piece of work, one of the most accomplished tablet web-apps I've yet seen, and has received much attention from the publishing and mobile industry alike. I've frequently heard it contrasted favourably with the approach of delivering native apps across different platforms, and held up as the shape of things to come. Andrew quickly dispelled any notion I had that this had been a straightforward effort, by going into detail on some of the approaches his team had taken to launch the product:

• Balancing of content across the horizontal width of the screen;
• Keeping podcasts running by having HTML5 audio in an untouched area of the DOM, so they'd not be disturbed by page transitions;
• Categorisation of devices by screen width;
• Implementing the left-to-right carousel with 3 divs, and the detail of getting flinging effects "just so";
• Problems with atomic updates to app-cache (sometimes ameliorated by giving their manifest file an obscure name);
• Using base64 encoded image data to avoid operator transcoding;
• How to generate and transfer analytics data with an offline product;
• Difficulties handling advertising in an offline product;
• Problems authenticating with external OAuth services like Twitter or Facebook, when your entire app is a single page;
• Horrendous issues affecting 8-9% of iPhone users, who need to reboot their phones periodically to use the product (I picked this up from a colleague of Andrew's in a chat before the talk);
• Lack of hardware-accelerated CSS causing performance problems when trying to implement pan transitions on Android;
• etc.

All of this really drove home the amount of work which had gone into the product: app.ft.com took a full-time team of 3 developers at Assanka 8 months to launch on iPad, and that team a further 4 months to bug-fix the iPad and ready for distribution to Android tables. (It's not available for Android tablets just yet, but that's apparently due to a customer-service issue: the product is there).

Seeing the quality of the product, I've no doubt that the team at Assanka know their stuff; and given the amazing numbers the FT report for paying digital subscriptions and their typical pricing for subscriptions, I'm sure the economics of this have worked well for them.

But the idea that it takes 24 developer-months to deliver an iPad newspaper product to a single platform using web technologies is, to me, an indication of the immaturity of these technologies for delivering good mobile products. By comparison, at FP we spent 20 months launching the Glastonbury app across 3 completely different platforms and many screen sizes; but this 20 months included two testers and two designers working at various stages of the project; development-wise I'd put our effort at 13 months total. Not that the two apps are equivalent, but I want to provide some sort of comparative figure for native development. I'd be very interested if anyone can dig out how long the FT native iPad app took…

And the fact that it's taken Assanka a further 12 man-months to get this existing product running to a good standard on Android is, to me, an indication of the real-world difficulties of delivering cross-platform app-like experiences using web technologies.

It strikes me that there's an unhelpful confusion with all this web/native argument: the fact that it's easy to write web pages doesn't mean that it's easy to produce a good mobile app using HTML. And the fact that web browsers render consistently doesn't mean that the web can meet our cross-platform needs today.

Adam Cohen-Rose took some more notes on the talk, here.

(At some point in the coming months I promise to stop writing about web/native, but it keeps coming up in so many contexts that I still think there's value in posting new insights.)

Comments

[Steve Pinches]

Tom - Steve Pinches here - FT product manager in charge of the Web App. I'd like to clarify a couple of things here as I mentioned on email, just so we're clear. It'd be a shame for the message taken from this to be that web app development takes longer than native, as our experience is certainly that that isn't the case. We're not wedded to one approach or the other, and you'll see a variety of different approaches being taken by us web vs native vs hybrid as we take things on a case-by-case basis. But, to clarify on your post above:

Whilst the *core* web app development took around four months of 3 full time developers, we have spent a lot of time with Assanka on feature development and optimisation.

In addition to this, the core development was predicated on some previous work done for our Samsung native app. We now maintain ongoing resource at Assanka for new feature development, as well as for rolling the app out onto multiple platforms.

So while Andrew's correct that Assanka have spent that kind of length of time on the app, it would be wrong to represent this as the time required to 'deliver the web app', as a great deal of time has been put in to developments we have either recently put live or are about to put live.

The important point here is not to infer that the time was spent due to the technology being immature or difficult to use; it's mostly because we have spent time, effort (and money!) getting the user experience right, tweaking behaviours, improving advertising propositions, delivering new features, etc etc.

It would be like saying that it's taken 15 years to build FT.com which, clearly, it hasn't.

[Tom Hume]

Hey Stephen - thanks for jumping in.

Are you able to provide comparative figures for your web vs native apps? You're one of very few organisations who have built an equivalent product using both methods, it'd be great if you could share

And any feel for how much over and above the core 12 man-months was spent on feature development and optimisation? It reads to me like the effort from scratch for the iPad-only version of your web app was something between 12 and 24 man-months (lower bound being your 4 months for 3 developers, upper being the figure I was given by Assanka). The difference between the lower bound and actual effort would be whatever was reused from Samsung, plus feature development and optimisation.

I'd certainly count getting the UX right, tweaking behaviours, adding new features, as being part of the product development (we did some bits of that with the Glastonbury app I'm contrasting with).