Monday, February 7, 2022 [Tweets] [Favorites]

The Danger of Sideloading Chromium

Peter Ammon:

The sideloading debate is really about Chrome. Sideloading Fortnite is about money, but sideloaded Chrome is an existential risk, threatening to do to iOS what it has done to Windows and Mac.

Peter Ammon:

So many users live in Chrome and use nothing else. You may think that development is good or bad, but it’s obviously undesirable from Apple’s perspective, since it gives Google extra leverage over Apple’s products.

If your users live in Chrome, then you are at Google’s mercy. You are dependent on Google to make any changes. Apple can add features like Do Not Disturb, but they’re borderline useless if Chrome doesn’t use native notifications, which for many years they did not.

It’s hard to find examples on the Mac side. But on iOS, it would be bad (from Apple’s perspective) if features like Face/TouchID web auth, Apple Pay, Pencil, iPad trackpad, etc. required Chrome support before any users saw them. That’s the existential risk to Apple.

Jen Simmons, Apple Evangelist:

Gosh. Catching up with tech Twitter this morning and there seems to be an angry pocket of men who really want Safari to just go away.

Do we really want to live in a 95% Chromium browser world? That would be a horrible future for the web. We need more voices, not fewer.

Ironically, Apple believes that the way to ensure this is by only allowing one voice on iOS. In the short term, that probably is slowing the advance of Chrome, albeit by preventing Apple’s customers from accessing certain sites and features. But this is depressing as a long-term strategy.

Safari should not merely be good enough to keep iOS users from abandoning the platform in order to switch browsers. It should be good enough that Apple doesn’t fear Chromium browsers taking over if users were allowed to choose. Exclusive features help, but they alone are not the answer. Users and developers both need better compatibility with the Web as it is, not as Apple wishes it were. I prefer Safari, but I can’t always use it. If macOS restricted browsers the way iOS does, I would have to get a PC or run an emulator or something.

Similar logic applies to the debate around Web apps vs. native apps on the desktop. The way to avoid a monoculture and get more native apps is not to ban Web apps. It’s to make it so that native apps can do more and work better, so that developing, distributing, and selling them is easier—so that users and developers choose them.

To bring this full circle, I’m not sure I want to know the percentage of people who buy Macs to essentially use them as really nice Chromebooks. Here the dominance of Chromium works to Apple’s advantage, in a way, because currently Apple makes the best notebook hardware for running Chrome. But in terms of what’s best for the Web and for macOS as vibrant platforms, I hope it’s not satisfied with this outcome.

Previously:

Update (2022-02-08): Lea Verou:

That is so awfully dismissive and tone deaf. No, people don’t want Safari to “just go away”. People (of all genders!) want Apple to respect user choice and stop forcing everyone to use Safari on iOS whether they want to or not. It’s pretty simple, really.

Damien Petrilli:

If [sideloading Chrome being an existential risk vs. Fortnite being about money] was the case, Apple would have lessen the grip on the App Store to remove the pressure while keeping the “only webkit engine” rule on iOS.

That would have been a lot easier to win in court. Instead, they fight to keep all the money and the 27% in NL is a hint to it

“Games account for approximately 70 percent of the entire App Store’s revenue, and 98 percent of in-app purchase revenue.”

If an alternative game store opened and made them lose all this money—as the App Store isn’t competitive enough-pretty sure Apple would be pissed

Peter Ammon:

I think this is exactly what will happen. We already see it somewhat with the drop to 15% commission. Of course Apple will fight court rulings, but if my theory is right, side-loading is the hill they’ll die on. We’ll see!

Jonathan Deutsch:

Apple had serious insecurities what opening up might mean.

They didn’t want iOS to become the Mac, and they didn’t want the Mac to become Windows.

Control is in Apple’s DNA.

[…]

Flash scarred Apple as a 3rd party causing the top system instability.

There used to be openness voices that could push back before the EPMs took over. Now their worst instincts are forefront.

Jeff Johnson:

Everyone whines about Chrome “taking over”, but nobody talks about how Safari had literally a 6 year head start over Chrome (January 2003 vs. late 2008/early 2009) but was surpassed nonetheless on the desktop.

How did Apple let that happen? Looks like gross incompetence to me.

And Chrome used WebKit until 2013. However, Google was able to massively promote Chrome using its own Web properties, and there’s not much Apple could have done about that other than stop funneling users to Google Search.

Why did Apple drop Safari for Windows? They ceded that whole market both for users and for web developers. Massive mistake.

Where’s Safari for Android?

Google bothered to write a web browser for iOS. Apple did not bother, and then Apple whines about losing?

[…]

The irony is that Apple aided and abetted Google’s dominance in a number of ways.

Apple happily took Google money to make it the default web browser in Safari. Still does!

Apple was a ringleader in the WHATWG coup to overthrow the W3C. Now a few browser vendors control the web.

I would argue that iOS lockdown actually hurt Firefox the worst of the major browsers[…]

Alex Riviere:

There is no way to debug mobile safari on anything other than a Mac. This is a very high barrier of entry to debug slight rendering differences on safari.

Michael Love:

It’s not just about web. App developers are subject to our own monoculture because Apple intentionally limits Safari to prevent web apps from competing with native + force us to the App Store.

It’s literally the Same. Exact. Thing. that Microsoft did with IE 20 years ago.

If we’re going to be stuck with a monoculture either way, I’d prefer a monoculture built around open-source Chrome over one built around a proprietary app store and closed-source frameworks.

See also: Jen Simmons, Ryan Christian.

Update (2022-02-11): Hartley Charlton:

Apple has also been criticized for demanding apps that browse the web to use the WebKit framework and WebKit Javascript on iOS and iPadOS, a policy that effectively bans non-WebKit based browsers. This has caught the attention of regulatory agencies, including the UK’s Competition and Markets Authority (CMA), which said that “due to the WebKit restriction, Apple makes decisions on whether to support features not only for its own browser, but for all browsers on iOS.”

[…]

Following consultation with developers, the CMA is considering forcing Apple to reverse the ban on non-WebKit based browsers to allow for more competition. It is unclear if Apple’s latest push for feedback is related to the growing regulatory pressures around Safari.

Bruce Lawson:

The interesting predicate of this argument is that Apple intend to keep Safari as the sad, buggy app that they’ve allowed it to wither to, because it has no competition. I emphatically do not want Chromium to win. Quite the opposite: I want Apple to allow the WebKit team to raise its game so there is an excellent competitor to Chromium.

WebKit is available on Windows, Linux and more. Safari was once available on Windows, but Apple silently withdrew it. SVP of software Eddy Cue, who reports directly to Tim Cook, wrote in 2013

The reason we lost Safari on Windows is the same reason we are losing Safari on Mac. We didn’t innovate or enhance Safari….We had an amazing start and then stopped innovating… Look at Chrome. They put out releases at least every month while we basically do it once a year.

There is browser choice on MacOS, and 63% of MacOS users remain with Safari (24% use Chrome, 5.6% use Firefox). As everyone who works on browsers knows, a capable browser made by the Operating System’s manufacturer and pre-installed greatly deters users from seeking and installing another.

Update (2022-03-09): Jack Wellborn:

By going all in on JavaScript-based cross platform development, Microsoft has clearly decided to become Google before Google becomes Microsoft.

So why doesn’t Apple want to support progressive web apps? People assume it’s just because progressive web apps would hurt App Store revenue. While I am sure that’s certainly a factor, I suspect the App Store is the least of Apple’s concerns. Like Microsoft, I suspect Apple sees progressive web apps as an existential threat. Unlike Microsoft however, Apple can’t address this threat by completely embracing progressive web apps. At the end of the day, Microsoft can become Google because they are both software and services companies.

See also: Hartley Charlton.

Update (2022-06-24): Alex Russell (via Hacker News):

Contrary to claims of Apple partisans, iOS engine restrictions are not preventing a “takeover” by Chromium — at least that’s not the primary effect. Apple uses its power over browsers to strip-mine and sabotage the web, hurting all engine projects and draining the web of future potential.

20 Comments

This is seems a bit naive. People are lazy and expect only good enough, hence PWAs. This is why most everything eventually slides to mediocrity. Not to mention the likelihood of a web browser more leaking private data. That is what Chrome is built to do.

It’s incredible that Chromium has outpaced WebKit so thoroughly, especially when you consider that Chromium is a fork of WebKit.

Given Apple’s financial resources, there’s no reason they shouldn’t be competing to be the best browser.

There is a base assumption under all of this: that anything Google comes up with is automatically a good thing for the web and that everyone else is "falling behind". Yes, Apple has some bugs to fix and work to do, but what I really want, and what I think is really important, is a diversity of priorities and perspectives about what the web should be.

Google's propaganda has worked so well that if they were allowed on iOS, that would be it forever. They would become the owners of the web and there would be nobody to stop them. It's truly unfortunate, but that is the situation we are in. It is totally understandable that Apple does not want that to happen.

Old Unix Geek

The fact Apple can ban Chrome on iOS is what makes them lazy. If they couldn't, they'd be forced to invest more in improving their (and others') browsers. So this is a direct example of where their monopoly power is harming users.

We seem to have forgotten that adversarial situations are a forcing function for progress in a world where profit can best be maximized by not investing. Technological improvements occur when companies compete, or countries do, particularly during war. It's not a question of people not being able to invent during other times, but a question of the difficulty of marshaling resources.

@Brad Who’s assuming? Many Web developers may simply like the stuff that Google comes up with. Google does seem to be trying to meet their needs. For me, as a user, it doesn’t really matter whether Google’s ideas are good or it has good motives. I commonly run into sites, some very important, that don’t work in Safari. This was not the case 5–10 years ago. If this is, as I suspect, more due to bugs than philosophical issues around PWA, it’s even worse that we/Apple are in this situation because it would be needless. By the way, there are also Chromium browsers like Brave that have compatibility with Chrome but privacy values more along the lines of Apple’s, and those are banned on iOS, too.

Brave is not banned for iOS. I use it on my iPhone and iPad.

> Safari should not merely be good enough to keep iOS users from abandoning the platform in order to switch browsers. It should be good enough that Apple doesn’t fear Chromium browsers taking over if users were allowed to choose.

I suspect more users would be lost to web site banners insisting on Chrome than to end user feature discrepancies. Telling users to “just download Chrome” is an alluring solution to publishers that don’t want to fund testing multiple browsers, let alone multiple platforms.

You mention using Safari except when you can’t. That sort of browser affinity feels uncommon. After hitting a couple of sites that insist on Chrome, I suspect most users would be gone for good. Firefox has suffered from this for years.

I don’t know the solution. Personally, I want multiple rendering engines to thrive on all platforms. But the majority of real-world developers have to be willing to consistently prioritize and put real money behind that goal. As it stands today, Apple has unique leverage through iOS to force that willingness.

"People are lazy"

Then why aren't they just using Safari on Macs? Why install Chrome at all, if all of this is just a matter of laziness?

"expect only good enough, hence PWAs"

Or, alternatively, web apps have advantages that make them genuinely better options than native apps for many people in many situations.

"There is a base assumption under all of this: that anything Google comes up with is automatically a good thing for the web and that everyone else is "falling behind"."

I don't know if anyone has such a "base assumption," but I've never seen it. What I *have* seen is people who build web apps investing a lot of resources just to get them to run adequately on Safari, which often makes up a single-digit percentage of their user base.

"Google's propaganda has worked so well that if they were allowed on iOS, that would be it forever"

Or it would force Apple to actually compete with Chrome, which would result in Safari working much better across a wider swatch of websites, which would result in more people using Safari, which would result in Chrome being less of a dominant force.

It's very obvious that Apple sees web apps as a threat. But instead of offering an alternative that is genuinely better, their approach is to harm progress for web apps as much as possible, by directly holding up W3C standards, or just not implementing them in Safari. That's not good for anyone - long-term, not even for Apple, because all it really achieves is solidifying Google's stranglehold over the web.

What I've seen are two set of entrepreneurs calling it quits at our first meeting because I told them about Apples 30% tax. All of their needs could have bee met with a fairly simple PWA on android, but not on iOS.

Fighting a dominant player by clinging on to a monopoly is hare brained. It's also delicious to see how fast people seem to have forgotten about Apples latest security blunder. The one where all browsers on iOS were compromised because.. "We care about your integrity"

@bob Brave on iOS has to use WebKit, so it loses the compatibility benefits.

@Plume Yes, exactly. It’s like, suppose (back when it was new) that you think JavaScript on the Web is a bad idea. Honestly, I do find sites that overuse it annoying, and I often wish that certain pages were more like plain old documents. But JavaScript has good uses, too, and a browser without JavaScript is not going to have good survival characteristics. Especially if it offers no compelling alternative vision and drops support for the most popular desktop operating system. You can’t just sit on the sidelines and tell people they shouldn’t want JavaScript.

And now we are in a situation where Chromium already has dominant marketshare. There doesn’t seem to be a strategy to try to catch it because Apple disagrees with the entire direction. I guess one can look at this as a noble stand for Apple’s restricted vision of the Web, but in practice it leads to Google having more control over how the Web evolves. Apple can’t stop Google by ignoring it. The best case for the current path seems to be that Apple is able to slow things down a bit, thread the needle, and stay just close enough behind that its users don’t jump ship. Meanwhile, software continues to move to the Web because of the inherent server-based/multi-platform advantages and Apple’s war with native developers.

Pierre Lebeaupin

I see a lot of what I can best describe as entitlement on the part of many web app evangelists, where they consider anything that lands in Chrome/ium to be a de facto web standard and Safari therefore instantly as dragging down the web by not adopting it there and then. This is at odds with the fact there is an actual web standards body that defines them, and while many Chrome features are at least proposed standards, some aren't. Moreover, even in the former case Apple has rejected implementing some features, at least as currently defined, because of privacy concerns (e.g. your battery level or Bluetooth environment could be used as a fingerprint). Finally, in some cases Chrome provides an API purely as a way to ostensibly bridge the gap between web apps and native apps, only for everyone to later realize the API is so ill-thought out and deficiet in its principle that redoing it completely is necessary; for me, this is what best characterizes Application Cache, which was so exposed by Jake Archibald's legendary article as having no clothes that it had to be not updated, but entirely replaced as a standard by Service Workers (not the best example since AppCache did get implemented in Safari, but there are other such APIs).

Don't get me wrong, I am sympathetic to some of these concerns, especially as I am investigating not so much PWA as offline-only web apps as a way to circumvent Apple's Gatekeeper, and as a result have to forego some niceties only available in Chrome so that what I do works out of the box on the Mac or at all on iOS, but let's just say not all criticism of Safari I see on the web appears grounded in sound engineering…

We found a number of bugs around media playback and CSS when working on NPR's "Joy Generator" stories. We wrote them up here: http://blog.apps.npr.org/2021/08/31/joy-generator.html

I'm actually sympathetic to the idea that Safari isn't going to implement stuff like WebUSB or Bluetooth or whatever. As a web developer, I don't miss those. But a browser that can't reliably play video, has restrictions on audio, breaks IndexedDB on a regular basis, has slow paths for CSS animations that aren't documented, and so on... it's not that Safari fails to keep up with the bleeding edge, it's that it's also not reliable for the features that it does implement, and that were standard years ago.

"they consider anything that lands in Chrome/ium to be a de facto web standard"

There literally are standards, and Apple is sabotaging them, and when sabotage fails, ignoring them.

"what I can best describe as entitlement on the part of many web app evangelists"

They're such entitled brats for wanting to provide good products to iOS users, and not wanting Google to own the web.

"because of privacy concerns"

Because there's absolutely no way Apple could possibly figure out how to implement these standards in a way that respects their users' privacy.

In the end, none of these points really matter, because you're arguing about whether Apple's principles are well-intentioned, while everyone else is arguing about the actual real-world outcome their behavior produces, which is to hand monopolistic control over the most important application platform to Google.

I'm sure everybody at Apple has the best of intentions. Meanwhile, Google has market share, which matters a lot more than intentions.

“they consider anything that lands in Chrome/ium to be a de facto web standard”

There literally are standards, and Apple is sabotaging them

I don’t think that paints an accurate picture.

A lot of the time, 1) Chromium implements a feature, 2) Google immediately submits a draft spec for a potential future standard, 3) web developers start using the feature, 4) web developers realize WebKit doesn’t implement it yet and blame Apple.

For example, yes, Chromium has implemented Web USB for years, and Safari doesn’t. But Web USB has the status of “Draft Community Group Report”.

Is Apple “sabotaging” standards? In some cases, maybe. In other cases, they raise objections to refine the standard. Which you would think is how a standards process should work: multiple stakeholders ultimately agreeing on a compromise.

In effect, Chromium tries to unilaterally push their vision of the Web. That said, I will agree that Apple needs to push harder for theirs.

Pierre Lebeaupin

What I argue (or at least, I think I do) is that Google gets so much credit on the part of most web developers that it benefits from a double standard, in which ways where Chrome "thinks different" tend to be interpreted as a common good, while ways where Safari "thinks different" tend to be interpreted as hostile animus.

And I have proof of that.

For the longest time, support for File APIs in Chrome was slow (it may still be; I haven't been able to check lately), much slower than in other browsers, because of overhead (on the order of a few milliseconds) per call to a file API, regardless of the size of data loaded: http://www.romhacking.net/forum/index.php?topic=20730.msg294230#msg294230 . I had to develop an asynchronous cache specifically so that performance would be acceptable in Chrome: the cache does not so much help by reducing the frequency of file system accesses per se, than by reducing the frequency of calls to the web APIs: even the recommended postMessage() to ourselves features unacceptable overhead on Chrome.

The second proof is this crasher, that is impossible to work around, and which they never fixed: https://bugs.chromium.org/p/chromium/issues/detail?id=776572 . In a comparable situation, the WebKit guys treated my report seriously: https://bugs.webkit.org/show_bug.cgi?id=164458 (I confirmed the fix when it landed in tech preview 19).

Don't get me wrong, I have no trouble believing that Safari has more issues and is less conductive to PWA development than Chrome. But as much as Safari does need a swift kick in the ass in specific areas, making it subject to unfair criticism is not the way to accomplish that.

"A lot of the time, 1) Chromium implements a feature, 2) Google immediately submits a draft spec for a potential future standard, 3) web developers start using the feature, 4) web developers realize WebKit doesn’t implement it yet and blame Apple."

That's not what happens. People are completely aware of the fact that implementing stuff takes time.

What actually happens is that Apple just flat-out announces that they're going to ignore finished standards like the Web MIDI API (which just happens to be a standard that threatens its control over app development, which, peculiarly, seems to be the case for many of the standards Apple elects to pretend don't exist, or implements in an intentionally broken way).

Apple seems to think that ignoring Web MIDI hurts Web MIDI, but actually, it just means that more things will tell people to install Chrome.

"in which ways where Chrome "thinks different" tend to be interpreted as a common good, while ways where Safari "thinks different" tend to be interpreted as hostile animus"

Assuming you're right, so what? Chrome has the market share, they gained it fair and square, not through OS bundling, but through being better. Even if that's the only reason people default to using it as the primary dev target platform, that still doesn't help Safari.

Apple can either whine about how unfair everybody and the universe is, or they can compete. If they don't want Google to gain monopolistic control over the web, I suggest they start doing the latter.

"making it subject to unfair criticism is not the way to accomplish that"

At this point, I have almost monthly meetings with my devs where they implore me to finally make the decision to drop support for Safari, every time coming up with a fresh new list of things they had to work around. This is not "unfair criticism", this is a browser that requires much more investment than either Chrome or FF, produces worse outcomes than both of these, pisses off developers, and commands a minuscule market share in many cases.

This is a bad situation, and pretending it isn't bad isn't going to make the bad go away, it's only going to make Safari go away.

What actually happens is that Apple just flat-out announces that they’re going to ignore finished standards like the Web MIDI API

Firefox objects to it as well, citing security concerns.

It’s also not a “finished standard”; it’s in draft status.

Chrome has the market share, they gained it fair and square

Oh come on. They gained it by heavily advertising for it on their own platforms and by implying in some of those ads that something about non-Chrome browsers as inherently inferior. Google can and does play dirty when it feels like it.

Nothing about the browser market has every been “fair and square”. There was never a time when people actually made an informed choice and installed the browser they thought was best. It was either the browser the ISP bundled for them, or the browser bundled by the OS, or the browser that lied about other browsers.

Between being advertised on Google.com and being preinstalled on a device, I’d have to say being preinstalled is the weightier side of the scale.

Speaking of chrome exclusives, look at this
https://runwayml.com

Quick and powerful video editing in the browser

Pierre Lebeaupin

By the way, for any interested party I found more specific references (that I initially misplaced) on the file API slowness in Chrome:
- Mailing list discussion (note the praise for providing a detailed, researched, actionable report) https://groups.google.com/a/chromium.org/g/chromium-discuss/c/iKxJ8FKCJzU/m/wsNJYlchCQAJ?pli=1
- NPM package for a JavaScript file API cache so trivial that it ought not provide a 10x performance improvement compared to directly calling browser APIs, yet here we are; description contains benchmarking in various situations https://www.npmjs.com/package/simple-file-cache
- Chromium bug, which I did not start but contributed to. Still unsolved. https://bugs.chromium.org/p/chromium/issues/detail?id=349304

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment