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. 2.5.6 caps web progress at the rate that Apple (under) invests.
-
Show this thread
-
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. The easiest iOS device sale is the upgrader who is worried about losing their software if they switch horses.
8 replies 15 retweets 205 likesShow this thread -
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.
41 replies 258 retweets 804 likesShow this thread -
If you make your living on the web, it's crucial to understand that Apple is *not on your side*. Every dollar you spend on iOS hardware is a vote against your future.
21 replies 134 retweets 481 likesShow this thread -
A necessary addendum: don't take this out on the WebKit team. All of these decisions were made far above their pay-grade. They want a web that can work just as much as you do. Yes, they're Apple employees, but just as oppressed by this as the rest of us.
13 replies 29 retweets 395 likesShow this thread -
Replying to @slightlylate
They aren't all Apple employees
But yes, good thread. If I may mention a separate but related issue, it's hard to say which is more damaging for the web out of this and Google essentially privatising it by making sure their sites only work optimally in their browser. Also AMP.1 reply 0 retweets 4 likes -
Replying to @cwiiis
Hi Chris, I'm one of the point people for making Google sure sites aren't (or don't stay) Chrome only. LMK if you see new ones. That said, a frequent cause is lack of useable features in other browsers when trying to do ambitious things. I ask teams to publish these lists.
2 replies 0 retweets 2 likes -
Replying to @slightlylate @cwiiis
We (Chrome) do not want a Chrome or Chromium-only world. It's harder to make progress on this when other browser teams under-fund engine development, tho. Puts well-meaning teams in a tough bind.
1 reply 0 retweets 2 likes -
Replying to @slightlylate
Yes, true - though there's definitely a responsibility for a company with as vast resources as Google not to just muscle through.
2 replies 0 retweets 2 likes -
Replying to @cwiiis
This isn't abstract; it's about shipped bits we don't control. A quick example: Service Workers on Google's biggest properties. These are *hugely* latency sensitive services. If rollout of a feature slows things down, that can block a launch. Enter Navigation Preload.
1 reply 0 retweets 1 like
Nav Preload is a feature we designed in collaboration with Facebook and the Site Isolation team as they were looking into the latency impacts of Service Workers. It gets things started much sooner, allowing us to avoid blocking network fetches on (potentially slow) disk.
-
-
Replying to @slightlylate @cwiiis
Google's highest-traffic sites need nav preload to be able to enable Service Workers. This has been communicated to other vendors for a long, long time now. And yet (see the bottom):https://developer.mozilla.org/en-US/docs/Web/API/NavigationPreloadManager …
1 reply 0 retweets 1 like -
Replying to @slightlylate @cwiiis
The result is other vendors telling us how unfair it is that we don't offer these features to their browser. Except we can't. It'd be a worse experience for users if we did! Unlocking progress means both sides need to deliver.
1 reply 0 retweets 1 like - 10 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.