Comment by robocat
6 days ago
How else is Google supposed to "integrate" within iOS?
Safari and Messages etcetera link to within the closed Apple ecosystem - just like Windows. It can be between difficult to impossible to send an email or create a calendar item unless you use the iOS apps.
I'm definitely no Google fanboi but every answer being "Google are arseholes" feels dishonest.
The Chromium developer team absolutely kick arse and being open source is a true gift. Mozilla is badly failing to compete. Microsoft failed to compete with their first Edge rewrite, and now ironicalky MS "competes" using Chromium open source.
And why did Chromium have to split from WebKit? As an outsider it just looked like "because Apple don't want to play nice".
The story is always simplified to Google greedy arseholes. A typical response: you can never ever ever satisfy open source proponents... The stereotype that every open source user greedily wants more.
iOS has an option to set your default browser and mail client, and it works fine. There is nothing even vaguely difficult about sending an email or creating a calendar item without using the Apple apps. Google is in fact being an asshole by prompting every time if you want to ignore the default app and use chrome in the hopes that you'll finally accidentally hit it.
> default mail client
Thanks - I never discovered that - sorry.
> There is nothing even vaguely difficult about sending an email [] without using the Apple apps.
While offline, I can attach a photo to an email with the Apple mail app and Q it to send later. However Gmail pauses or fails if slow connection. I've always assumed (perhaps unfairly) that was due to an iOS API issue - but perhaps the Gmail app is buggy?
> or creating a calendar item without using the Apple apps.
Not sure what I'm doing wrong then - I don't even have the Apple calendar app installed and somehow I hit problems.
I guess I default to blaming Apple - over the last year I have found my iPhone to be unreasonably buggy. Or I could be emanating anti-tech radiation.
>While offline, I can attach a photo to an email with the Apple mail app and Q it to send later. However Gmail pauses or fails if slow connection.
This is not really google vs apple. You are describing webmail vs old school mail client. One uploads the attachment immediately, the other does not.
> While offline, I can attach a photo to an email with the Apple mail app and Q it to send later. However Gmail pauses or fails if slow connection. I've always assumed (perhaps unfairly) that was due to an iOS API issue - but perhaps the Gmail app is buggy?
This is most likely a Gmail issue. How apps behave on an unreliable connection is entirely up to the developer.
> 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.