I agree with the “enforce competition laws” sentiment, but in this context, enforced naively, all it’ll do is entrench the dominant browser engine, Blink, even more across the mobile ecosystem.

I’m sure some devs will love this. But equally, some may worry about the monoculture implications.

▲

dekoidal 9 hours ago | parent | next [-]

It hasn’t on Macs. Safari is still popular among non-tech folk

▲

cosmic_cheese 8 hours ago | parent | next [-]

It’s still got popularity within tech-inclined Mac/iOS circles too because it’s easier on the battery than Chrome (+derivatives) and Firefox. Some would like to switch but because neither Google nor Mozilla has much to lose for their browsers being battery hogs, relatively little engineering effort gets dedicated to improving efficiency compared to WebKit (which is similarly efficient under Linux in e.g. GNOME Web, proving it’s not purely first-party advantage).

▲

crossroadsguy 8 hours ago | parent | prev | next [-]

That’s because Apple adds two extra legs to Safari on OS level and cuts both the legs of other browsers in a manner of speaking by rigging this comparison.

	▲	argsnd 7 hours ago \| parent \| next [-]
		In what way do you think this is meaningfully occurring? I ask because I have not heard of Chrome or Firefox being inhibited on energy efficiency by platform limitations.
	▲	Klonoar 6 hours ago \| parent \| prev [-]
		This needs a big ol’ “citation needed” slapped across it.

▲

Spivak 8 hours ago | parent | prev [-]

I think the narrative is that once developers have the option to tell all of their users "we only support Chrome, just install Chrome" then any support for Safari will dry up.

Unfortunately I don't think we will see if this is how it plays out until Apple has to allow other browsers globally.

▲

leptons 7 hours ago | parent [-]

The reason Apple doesn't allow any other browser engines on iOS is due to them collecting up to 30% of purchases made through the apps from the app store. If a developer can do the same things with a capable web browser, then they won't need to create a native iOS app and that cuts into Apple's app revenue. So Apple purposely hobbles Safari so it doesn't have any advanced browser APIs for stuff like bluetooth or other APIs that apps have access to, forcing developers to create an app, where Apple can then cut into purchases made through the app.

It has nothing to do with people no longer using Safari and Apple being sad about that. Other browsers can technically be installed on iOS, but the underlying browser engine is forced to be Safari, which lacks many APIs other web browsers could implement, reducing the need for a native app. It's purely Apple's anti-competitive greed that drives this situation. And the EU, Japan, and the US DOJ have noticed. So far only the EU and Japan have actually taken measures to force Apple to change this.

Here's the entire DOJ lawsuit which includes many other instances of anti-competitive practices by Apple.

https://www.justice.gov/archives/opa/media/1344546/dl?inline

▲

otterley 7 hours ago | parent [-]

What evidence do you have, other than speculation, that Apple is so motivated? What standard features are missing from Safari’s rendering engine that makes it a less capable browser such that developers are forced to produce apps instead?

▲

koolala 5 hours ago | parent | next [-]

WebXR hasn't been supported for 10 years so they control their own AR market.

	▲	otterley 4 hours ago \| parent [-]
		How does it compare to, say, the experience on Android?

▲

leptons 3 hours ago | parent | prev [-]

Specifically for me, my company has a product that could use Bluetooth, but Safari will never implement the Web Bluetooth API, where Chrome has for some time on Android. So the workaround is to use Wifi instead (my product supports both bluetooth and Wifi), which drains the phone battery faster.

No, we do not want to write our own iOS app where Apple can then extort us for a percentage of any sales through the app, and we have to pay for the priviledge to develop that app, as well as buy Apple hardware to do so.

So instead we use Wifi, where we can maintain one single codebase - the web application, which works on both Android and iOS, but has to use Wifi. If Apple allowed Chrome to use its own browser engine, we would simply tell users to install Chrome to interact with our device. Then we don't have to pay Apple for anything, nor should we have to.

Apple purposely won't implement some APIs so they can force developers to create an app for their app store where they can collect money from any additional sales through the app. It's all spelled out in the DOJ suit, why won't you just read it??

https://www.justice.gov/archives/opa/media/1344546/dl?inline

	▲	otterley 3 hours ago \| parent [-]
		We’ve responded to this in a different thread. See elsewhere.

▲

concinds 7 hours ago | parent | prev | next [-]

The "monoculture" has never been less of a threat. WPT.FYI is driving towards asymptotically perfect compatibility and behavior. And the real web, the long-tail of websites, is too chaotic to be controlled by any entity regardless of browser market share. Chrome can cook up whatever API they want, no website can be forced to adopt it. And if someone can't use some WebMIDI site on Safari, well, they can't complain, they didn't want that site to exist in the first place.

It's simply not a good excuse to defend the iOS browser ban.

▲

shmerl 6 hours ago | parent | prev [-]

Banning competition can't possibly help increasing competition.

It would be good to see Firefox with its own engine there for example.