One unintended consequence of the accelerating popularity of HTML5 for mobile app development is an ability to skate past Apple’s App Store restrictions on in-app sales. So I put this question to Piotr Steininger of Tapangi Consulting:
There’s talk out there about being able to use HTML5 to get around Apple’s App Store ban on charging for in-app purchases. In other words (I think), somehow HTML5 allows content producers to get around this problem by making apps (and other things) downloadable directly through web browsers. So … how is it that HTML5 allows getting around this issue?
Some background: Apple announced a policy change earlier this year, specifically in Section 11.14 of its App Store guidelines, prohibiting charging fees for in-app sales of content:
Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, and video) that is subscribed to or purchased outside of the app, as long as there is no button or external link in the app to purchase the approved content. Apple will not receive any portion of the revenues for approved content that is subscribed to or purchased outside of the app.
(See Wired’s discussion of these changes here). “In-app sales” means just that: Sales or subscriptions for content or services from within an app, typically via use of external links taking a user to a purchase screen on the publisher’s website. Apple takes a cut of revenues from subscription sales, but only for in-app sales. Publishers had been directing traffic for premium services via links – within their apps – to the publisher’s transactional pages outside of the apps. Apple now takes the position that any such transactional sales traffic originating from within the app remains an “in-app” sale.
My question to Steininger involved understanding the growing use of HTML5 as a method – intended or not – to circumvent this restriction. But first I wanted to understand what exactly was “restricted” by this restriction.
Used to be – and perhaps often still is – that Apple could enforce this ban through its control of the apps themselves: In-app purchases of premium services and content simply couldn’t be made other than through additional access through the App Store. Further, mobile platforms didn’t support any ability to download, install, and run a fully loaded application that was self-contained. That was the state of technology until somewhat recently.
So first question … why (or how) was that so? Or in other words, what capability does Apple’s App Store make possible that – previously – browsers by themselves could not do?
Further background: Through Apple’s open source Webkit project, the mobile browsers Safari and later Chromium were developed to offer application cache. Or as Steininger put it, “when you load the app once, all the files necessary are going to be in a special place on your computer” – device-based local storage, permitting interactive and engaging user interface without needing any page loads.
“Rather than buying an app in the app store, you just go to a URL [READ: not Apple’s App Store] and you’ve got an app ready to go. For example, once you load [a book] on the iPad, you’re good to go if you lose connection – even if you close the browser, reboot the iPad and go to the same URL without a connection.”
And so that is what the Financial Times recently did. As MacWorld reported in June,
In recent months, [the FT has] been directing its subscribers to an iOS-specific, HTML5-based Web app that it’s developed. The Web app provides an iOS-like interface, with the ability to tap on articles to view them, adjust text sizes, and even share content via email, Twitter, and Facebook. The publication is also making video content available in its app, and it even prompts users to place a shortcut on their Home screen; that allows the app to run full-screen without Safari’s interface. And, of course, content can be locked down to just subscribers and registered users.
What changed recently? HTML5, with its (now) robust ability to “build interactive engaging UI without needing any page load” – as Steininger described it – using JavaScript in its now revitalized (or vitalize) application-building fullest form. As Steininger explained, “Now … the browser in effect replaces the platform. Or the browser IS the platform.”
Second question, what does it mean to say – and what significance – that the browser supplants the platform, or that a browser now facilitates local storage on the device? “No longer iOS, Android, etc. The [WebKit-based] browser is the platform:
- Storing all necessary files needed to run the application in “application cache”
- Storing arbitrary data off-line – there is no “local storage”, “webSQL” and other less widely implemented storage mechanism like indexdb.
What does this do for the FT or for Amazon? Users technically don’t need to go to Apple’s App Store to download an app, buy subscriptions, buy premium content and so forth. And publishers aren’t therefore limited in any way by Apple’s subscription rules, or revenue sharing. And if that much is true, as MacWorld noted, Apple cannot claim any interest in subscriber data, the big plumb for many publishers.
This raises obvious questions, not the least of which is how has Apple reacted to the move by Amazon and others away from the App Store? How have other major publishers reacted, and what should we expect to see? Answers to these questions may be more nuanced than might seem warranted at first glance. More on that separately.
Add Comment