{"id":27282,"date":"2019-11-18T16:05:32","date_gmt":"2019-11-18T21:05:32","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=27282"},"modified":"2020-03-05T09:04:02","modified_gmt":"2020-03-05T14:04:02","slug":"the-hotel-cupertino-clause","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/11\/18\/the-hotel-cupertino-clause\/","title":{"rendered":"The Hotel Cupertino Clause"},"content":{"rendered":"

Alex Russell<\/a> (Google employee):<\/p>\n

\n

There seems to be confusion about how, exactly, Apple keeps the web second-class on iOS. Understandable! It’s the interplay of several interlocking effects. Let’s examine them (thread).<\/p>\n

First, no matter how app-like it is, Section 4.2 of the App Store Review Guidelines excludes web experiences from being discovered via the search box where users go to add things to their homescreen.<\/p>\n

[…]<\/p>\n

Next, Apple under-invests in Safari’s engine (WebKit) in ways that cumulatively make it difficult to do anything new and ambitious.<\/p>\n

[…]<\/p>\n

On every other OS, the way we have dealt with laggard browsers is through competition.<\/p>\n

[…]<\/p>\n

Section 2.5.6 is the Hotel Cupertino clause: you can pick any browser you like, but you can’t choose a better web. In fact, iOS prevents other browsers from even replacing Safari as the system default.<\/p>\n

2.5.6 caps web progress at the rate that Apple (under) invests.<\/p>\n

All of this has been done to preserve the linkage between proprietary OS\/APIs, an exclusive software ecosystem, and the hardware sales that software ecosystem supports.<\/p>\n

If you’re a web developer, this means that iOS -- the whole OS -- is the new IE6. Your CEO and wealthiest users won’t switch off it, so it taxes everything you do. They also can’t imagine the web being great because, for them, it isn’t.<\/p>\n<\/blockquote>\n\n

Russ<\/a> Bishop<\/a> (Apple employee):<\/p>\n

\n

That’s rich, coming from the company that abused its #1 search position to drive adoption of Chrome, forked Blink from WebKit, and slams new APIs through without considering perf\/privacy.<\/p>\n

“Open Web” from Google is code for “whatever Is best for Google and ad-tech this week”<\/p>\n<\/blockquote>\n

You were the ones that decided to fork from WebKit, dividing what had been the largest community of devs working on web technologies.<\/p>\n

You did it because YOU want control of the web.<\/p>\n

As if best battery life and privacy is “under-investing”.<\/p><\/blockquote>\n\n

Tony Arnold<\/a>:<\/p>\n

\n

Google forking WebKit was a thin cover for breaking down standards bodies of the time.<\/p>\n

It wasn’t altruistic. It wasn’t about users.<\/p>\n

Google are an advertising company that uses their tech to gather data to better sell ads.<\/p>\n<\/blockquote>\n\n

Miguel de Icaza<\/a> (Microsoft employee):<\/p>\n

\n

1. This has the upside of preventing the web to have a single provider in the form of Chromium. This is the last bastion of defense for diverse engines.<\/p>\n

2. It also slows down the standardization of fringe features that are done purely for Google’s needs and have no reason to be standardized.<\/p>\n<\/blockquote>\n\n

Orta Therox<\/a> (Microsoft Employee):<\/p>\n

\n

I’m pretty glad for the App Store rules that keep chrome from monopolizing all web browsers in every context, personally. Never been a Chrome user, but I think Safari do a good balance on user features vs dev wants.<\/p>\n<\/blockquote>\n\n

Matt Aimonetti<\/a>:<\/p>\n

\n

Both companies are terrible and both of you have valid points. Apple opts to be conservative and closed (therefore safer but also in a closed ecosystem), Google is pushing features, often for its own benefit, which leads to fragmentation and security threads<\/p>\n<\/blockquote>\n\n

Yes, both companies are pursuing policies that benefit them and which they also think are better for users. Users have multiple concerns, which are only partially addressed by each browser.<\/p>\n\n

On the Mac, I choose Safari because I like its emphasis on privacy, and I think it’s a better Mac app. But seemingly everyone I know who is not picky about such things uses Chrome because it’s always compatible. (Or, perhaps, it has such marketshare that sites are forced to adapt to it, but to the user that amounts to the same thing.) I am seeing increasingly many sites that don’t work properly with Safari, so for them I use Chrome or Firefox. The WebKit Goals for 2020\n<\/a> (via Hacker News<\/a>) don’t have much to say about this. It also annoys me that Safari beachballs for a few seconds every time it auto-fills a login. So I am always tempted to switch, but I don’t like any of the other choices that much.<\/p>\n\n

On iOS, of course, there is no choice. Microsoft famously got in trouble<\/a> merely for privileging its browser, not actively blocking competing browsers from running.<\/p>\n\n

Kyle Pflug<\/a>:<\/p>\n

\n

There’s a third axis here, which is “good for competition.” It’s difficult to deny (at least, in good faith) that iOS policies have the effect of making it more difficult for compelling alternate device ecosystems to take root (Google Play policies do the same thing.)<\/p>\n

The web has remarkable potential to be an equalizer and Apple is strongly disincentivized to invest in capabilities that enable that.<\/p>\n

Even when there are also good-faith reasons to prefer a walled garden (and there are many), it’s hard to not notice the more cynical motivations.<\/p>\n<\/blockquote>\n\n

Jamie Gaskins<\/a>:<\/p>\n

\n

I really wish people would stop using the phrase “the new IE6”. There is literally nothing in web development today that compares to developing for IE6.<\/p>\n<\/blockquote>\n\n

Nathanael Anderson<\/a>:<\/p>\n

\n

Actually I tend to agree it is the new ie6. Been around since pre-ie6. IE6 froze API in that era; so all these cool new API were unusable because of IE6. Safari is doing the same thing now. Lots of new shipping api’s are unusable because of having to support iOS...<\/p>\n<\/blockquote>\n\n

Bridger Maxwell<\/a>:<\/p>\n

\n

FWIW, when I port features from my iOS app to the web app version it is often Safari that is missing the APIs. The little examples add up. For example, touch and scroll input APIs don’t support Retina resolutions yet (they are all whole numbers). Other browsers do.<\/p>\n<\/blockquote>\n\n

There are lots<\/a> of<\/a> people<\/a> making fun of Google for counting the number of Web APIs implemented. But what other metric would make sense? It’s pretty funny because in the early days Apple bragged about the percentage of Web specs Safari implemented vs. other browsers, and at each WWDC it touts the number of new iOS and macOS APIs that it’s added.<\/p>\n\n

Previously:<\/p>\n