← Back to context

Comment by cosmic_cheese

6 days ago

> How else is Google supposed to "integrate" within iOS?

Like everybody else. If the user wants Chrome on iOS, they can install it and set it as their default browser. To link to other Google apps, Google can use Universal Links[0] to directly open Calendar, Sheets, etc or open the corresponding App Store page if they haven’t been installed yet.

Google forked WebKit because they wanted to take it in a direction that was fundamentally incompatible with the direction Apple wanted to go: Google wanted more core functionality (process management, etc) to be written as part of the browser (likely to serve as a moat) while Apple wanted all that to live within the engine itself so third party devs could take advantage of it without having to fork a whole browser (just drop WebKit into your app and go).

[0]: https://developer.apple.com/documentation/xcode/allowing-app...

> Google forked WebKit

Yes - working code that everybody uses now including a major competitor - Microsoft. Where's the alternative timeline with a WebKit browser on Windows? Oh, Apple killed v5.1.7 Safari on Windows in 2010 - their choice. Windows Safari had its issues but it was a great browser when it was released. Virtually nobody has chosen to base their browser on WebKit - and they choose not to for good reasons. Similarly why nobody forked Gecko - they didn't want that code.

> without having to fork a whole browser (just drop WebKit into your app and go).

But Apple failed at that goal - saying that WebKit works better as an engine is just not what happened in reality. WebKit was certainly a worse choice for open source engine on Windows back when Windows really mattered. Nobody used it.

> likely to serve as a moat

That is just making shit up. If Google wanted a moat then they could have built a moat. History has shown that the multiprocess design of Chromium was no moat. You might argue there are other moats - and that is what the DOJ seems to be arguing.

Link to the reasons the Chromium team wrote: https://www.chromium.org/blink/developer-faq/

Edit: I guess I would also like to link to a great response to "you must be the product": https://danfrank.ca/most-businesses-dont-work-that-way/ and we should always refer to Spolsky's "comoditize your complement" https://gwern.net/complement

  • WebKit never took off on Windows, true, but saying that it was a failure is a stretch. It’s served Mac and iOS devs well in the past 22 years, both as a full-featured embeddable multiprocess webview and as the core of alternative browsers (OmniWeb in the past, Orion today).

    The reason I believe that moving functionality out of the engine into the browser serves as a moat is because it gives Google more power to exert its will on Chromium forks.

    If Blink were fully independent, third parties wouldn’t be beholden to forking Chrome; they could just drop Blink into their bespoke UI. Google’s decisions in Chrome would be entirely irrelevant to these third party devs. As things are now, forking Chrome is for practical purposes required if you want to use Blink, and diverging from mainline presents a risk — the more divergent forks become, the more effort and developers it takes to keep up with patches. Few organizations have the kind of manpower required to move at the Chrome team's pace while also maintaining their own large sets of patches.

    This means that every decision in Chrome that forks disagree with adds more maintanence overhead, limiting the bulk of changes to those that are skin deep.

    Google may not have intended this effect from the outset but it’s certainly realized the leverage it gives them in the time since.