Apple is bad news for the future of the Web

and there is nothing we can do about it.

Apple, intentionally or not, is holding back the development of the web in 2016. Draconian policies enforced by Apple mean it can also continue to hold the web hostage to new web technology developments for the foreseeable future. Unless something drastically changes in their developer policies or their approach to staffing and developing their own web products this situation will not improve in the coming years and web applications will continue to play second-fiddle to native applications on iOS — and, to a large extent, on all mobile devices — for years to come.

What’s this all about?

Apple maintain a unique stranglehold over what web APIs, technologies and standards will ‘make it’ or not today and in the future. On every other platform alternative web browser engine choices exist and competition flourishes — pushing other browser makers along. Not so on iOS (Chrome, Firefox, Opera, et al on iOS are just running on top of the same iOS WebKit and JavascriptCore engines).

The crux of this point comes down to a single clause in the iOS Developer Program Agreement:

“ 3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework or JavascriptCore ”

At this point many people like to say that this clause actually works in the interest of iOS users. Not being able to run interpreted code means Apple can fully vet an application’s code before it hits the App Store. Application code can not change dynamically after an application is released. This is widely considered a Good Thing.

But then there is a curious exclusion to the statement above. The iOS developer license explicitly allows Apple to bypass these restrictions for their own WebKit and JavascriptCore products. Not web engines and JavaScript engines in general. It just allows Apple to run Apple’s version of critical web components that every iOS user interacts with every day (in Safari or within in-app web-based views or both).

But WebKit and JavascriptCore are simply not good enough

That Web Peer-to-Peer revolution? Not possible on iOS. Web-based instant conferencing via Webcam and Microphone? Not happening (available in other browsers since 2011). A way to provide system-level notifications from web apps? No. Or Service Workers for ‘app-like’ installation and offline support — perhaps ’the most important thing to happen to the web’ since the iPhone or since XMLHttpRequest? No again.

The list goes on and on. Fullscreen APIs, Gamepad APIs, WebVR APIs, Media Source Extensions. Let’s not even start on stubborn Video and Audio codec support choices or lack thereof or the quirks and bugs you run in to when trying to develop something remotely novel for the web — things that just work in at least one browser on every other mainstream Operating System available today.

The worst part is that it is hard to shake the feeling that Apple really treats us all like grains of dust. If they care at all about web developers, the web itself or the issues web developers and web users file against their web products then they do an excellent job of not acknowledging it. File a bug report or feature request to the WebKit tracker, as is the recommended practice, and you should consider yourself lucky if you see any progress on that issue in years. Even if your bug gets addressed and fixed it could then still take a year or more to see that fix hit actual phones in an iOS update.

It is possible to find years-old bug reports in the WebKit tracker for each of the unsupported features listed above. Putting all these pieces together makes it seem like Apple are not taking development of the web platform seriously enough.

Apple’s stranglehold over the web is locking up untold billions in economic value

By denying users a way to access voice and video conferences in a web browser, or share files peer-to-peer over a web site, for example, Apple is driving iOS users toward installing more and more native applications. But converting web users to install a native application does not always go well. There is a significant cost, both in lost users and overall service usage, in having to convert web visitors to your native application. A user can not just point their web browser to the same e.g. conferencing web page as their team and get on with things quickly.

You can not conceive of and launch a new web-based service for anything remotely advanced without also having to deal with iOS issues. You have the additional burden of having to create a native iOS workaround and then you have to accept that the majority of your users will not download your native application and not be able to get up and running quickly enough. That’s, of course, what the web can do best.

Whole startups do not and can not exist now or in the future without broad support of compelling new web technologies in the most popular devices and web browsers. And what is the impact on people’s productivity when they need to spend more time finding workarounds instead of getting on with things?

The question really is: how much is NOT aggressively developing the web platform really costing our economies?

No carrot on the end of the stick

I’m not suggesting that Apple engineers are not working incredibly hard. I am saying that the main focus of their effort — as a company — is not on the web platform. I, and others, consider that a problem:

Without a strong web focus, Apple have little incentive to add web features to iOS WebKit or JavascriptCore. If features happen to be required or simultaneously useful for embedding in Apple’s own native applications via WebViews then invariably we see lots of movement. Apple uses a lot of these WebViews throughout its native applications. If something is needed for one of these native applications you can be sure it will quickly appear in WebKit.

Otherwise…just don’t hold your breath.

The elephant in the room

Apple have a healthy business selling native applications through their iOS App Store. How healthy you ask?

“ The App Store is very key. It’s hard to believe that the App Store was launched only 7 years ago. It’s hard to remember a day without it. I’m happy to announce that the App Store recently passed a major milestone. The App Store has passed … 100 billion apps downloaded [whooping and applause from audience] ”

— Tim Cook, Apple CEO at WWDC 2015

100. Billion. Apps. Downloaded.

Apple’s cut of App Store revenues in 2015 alone amounted to over $6 billion dollars.

$6,000,000,000.

And that is 7 years that Apple have been living with what can only be described as a serious conflict of interest when it comes to the web.

How could the web ever compete with those numbers?

One guy at Apple got it

His name was Steve Jobs. Steve Jobs is Apple. Apple is Steve Jobs.

One of Jobs’s business rules was to never be afraid of cannibalizing yourself. “If you don’t cannibalize yourself, someone else will,” he said. So even though an iPhone might cannibalize the sales of an iPod, or an iPad might cannibalize the sales of a laptop, that did not deter him.

— Walter Isaacson’s biography of Steve Jobs

In that spirit, even if web applications could cannibalize native applications or iOS App Store revenues, that should not deter Apple from following the path of also pushing the web forward with the same or more vigor.

It is Apple’s choice to either cannibalize their native applications or let other platforms do it for them. In the latter scenario, at a certain point Apple will not be able to catch-up after having been left too far behind for too long. In the former scenario, new economic value can be produced by unchaining the web and allowing new web technologies to flourish. Apple would then be able to position themselves to capitalize on those changes in its own unique ways.

Innovate or die. Eat or get eaten. Let us in, Apple.