News for hackers. Stuff that matters.
Re:BrowserEngineKit – Apple Developer Documentation by mort96 on Friday January 26, 2024 @04:44AM (#39140614)
And finally, Chromium will be able to become the dominant browser engine on yet another platform.

I don't like Apple's restrictive policies. But the fact that Safari (or any non-Chromium browser) has 25% of the mobile market share is a good thing.

We'll see how effectively Google will manage to convince users to switch.

EDIT: As for the "you have the choice to stay within the walled garden" thing... no, you don't really. Developers have the choice to publish their app to the walled garden, but if I need a certain app, I don't have the choice to get that app through the walled garden. I will be forced to get the app where the developer of the app publishes it, just like I am currently forced to get the app through the App Store.

Re:BrowserEngineKit – Apple Developer Documentation by AshleysBrain on Friday January 26, 2024 @05:25AM (#39140982)
I used to think it was better to have Safari for browser engine diversity. However Apple develop Safari with such appalling negligence that it's changed my mind [1]. Having a single browser engine dominate is not a perfect situation and will have downsides. However it is still better than having to put up with Apple's negligence towards Safari.

[1] https://www.construct.net/en/blogs/ashleys-blog-2/safari-rel...

Re:BrowserEngineKit – Apple Developer Documentation by liamwire on Friday January 26, 2024 @07:05AM (#39141732)
Reading through these complaints, all of them seem to be your fault. It’s akin to the bike fall meme [1].

Firstly, you complain of a third-party dependency being broken in a preview build of Safari, and that you had went on holiday the week the stable version was published, meaning you couldn’t guarantee the problem was fixed in the stable release. Plainly, that’s an organisational problem on your end—the Safari team fixed the problem on their end. I’ll come back to your complaints re. release schedules.

Your second complaint is, in your own words, “we accidentally relied on a Chrome bug that meant our Service Worker was broken in Safari 16.4.” You go on to rehash your initial complaint, which is that Apple doesn’t publish a release schedule for Safari. I don’t inherently disagree with this complaint at face value.

Finally you move on to your third complaint, but to me it seems like yet another problem on your end. You made the observation that a given feature was supported and made the assumption that it was supported fully, with no other logic in place to test functionality or fallback to another rendering method. By your own admission again: “We detected OffscreenCanvas merely by seeing if it was defined. I never expected a browser to ship it with some contexts but not others - I assumed it would have parity with the standard canvas element.” I can understand the frustration and panic of being caught out here, but the pitfall is in your application logic. Your arguments afterwards with regard to supporting existing content are well said, but don’t generalise in this case. Just because something broke for you doesn’t mean everyone made the same flawed assumptions you did.

You then go on to list a random assortment of historic instances of Safari having flaws, as if that isn’t true of all browsers across the board.

[1] https://knowyourmeme.com/memes/baton-roue

Re:BrowserEngineKit – Apple Developer Documentation by AshleysBrain on Friday January 26, 2024 @07:36AM (#39141960)
I think you've misunderstood the point of the post. Of course bugs happen and things go wrong, including on our side. What makes it so much worse is Apple's opaqueness: no communication on bugs, no release schedule, no public plans. So we have no idea what will ship or when or whether catastrophic bugs will go to worldwide release or be fixed. For example how am I supposed to avoid booking a holiday when Safari's stable release happens, when the release date is an Apple secret right up until the very moment it begins its worldwide release? You can't blame me for messing up my planning there, because it's simply not possible, and it can result in a great deal of stress for developers like me.

All other browsers have enough communication and transparency to avoid this. Towards the end of the blog post I outline what Apple need to do - which all other browser makers already do - to make it at least vaguely tolerable to develop for Safari.

Re:BrowserEngineKit – Apple Developer Documentation by mort96 on Friday January 26, 2024 @05:38AM (#39141068)
I think it depends entirely on what your goals are. If you think diversity is gonna improve the browser engines, then yeah, Apple isn't gonna be much help with that.

However, if your goal is to prevent Google from having complete and total unilateral control of the web standards, simply the existence of WebKit as a prominent browser engine is enough. Its quality pretty much doesn't matter in this regard. This is pretty much my perspective.

Re:BrowserEngineKit – Apple Developer Documentation by factormeta on Friday January 26, 2024 @06:15AM (#39141349)
And what didn't Chrome forked from WebKit at some point with khtml from KDE. So yeah use WebKit more to avoid Chromium monopoly.
Re:BrowserEngineKit – Apple Developer Documentation by nolok on Friday January 26, 2024 @04:49AM (#39140654)
So that means you think microsoft should be allowed to force users to edge on windows ?

You do not fix a tech monopoly issue by imposing a duopoly, especially not with each one in their own little garden with no cross over.

And you don't fix the issue of one way too big tech company having full control over the web through their browser by giving it or some of it to another way too big tech company, especially if that other company has already shown its propension to use its control of the stack to protect its own interest.

The solution here is to do what we did in the early 2000s, and educate people about firefox + ublock. On desktop after a large growth notably in europe, Firefox stagnated in speed and that's how Chrome take its headstart, but on mobile with google insistence on no extensions the game is still open.

Re:BrowserEngineKit – Apple Developer Documentation by mort96 on Friday January 26, 2024 @04:56AM (#39140719)
No, I don't want Microsoft to force people to use Edge on Windows. I also don't want Apple to force people to use Safari on iOS; but even then, the argument for why one of the outcomes of this change is bad (i.e it will make Chromium even more dominant) doesn't apply to Edge, since Edge is Chromium.

I agree that nothing about the current situation is ideal. These changes won't take us from a good situation to a bad one, it will just take us from a bad situation to another situation that's slightly differently bad.

I hope you're right that uBlock Origin can get people to switch from Chrome to Firefox on mobile... but proper Firefox has been on Android forever, yet Firefox's market share on mobile is pretty much non-existent. Why hasn't the "educate people about firefox + ublock" strategy worked there? Why do we think it would work better on iOS?

Re:BrowserEngineKit – Apple Developer Documentation by elashri on Friday January 26, 2024 @05:01AM (#39140764)
> So that means you think microsoft should be allowed to force users to edge on windows ?

While this is a good question, It is not relevant to the point because Edge is still Chromium. So this still gives Google the dominant place it wants to take and monopoly on web standards.

Re:BrowserEngineKit – Apple Developer Documentation by nolok on Friday January 26, 2024 @05:03AM (#39140781)
This is a non answer imho. Are you saying if Microsoft goes back to their own engine, they should now be allowed to do it ? Microsoft using blink is a technicality that could be reversed as quickly as it was implemented.
Re:BrowserEngineKit – Apple Developer Documentation by elashri on Friday January 26, 2024 @05:05AM (#39140801)
I didn't provide an answer because I think while the question is good, it is irrelevant to the point the GP was raising. And no, I'm not saying what you are attributing to me.
Re:BrowserEngineKit – Apple Developer Documentation by Klonoar on Friday January 26, 2024 @05:17AM (#39140930)
> You do not fix a tech monopoly issue by imposing a duopoly, especially not with each one in their own little garden with no cross over.

You don't fix it by cementing a monopoly either.

> The solution here is to do what we did in the early 2000s, and educate people about firefox + ublock.

This was a much smaller tech-enabled population, and even that was moving mountains. I'm not saying it can't be done but it's important to recognize it's a very uphill battle since Chrome is not a bad browser and IE was.

This isn't even remotely the same game here.

Re:BrowserEngineKit – Apple Developer Documentation by Hamuko on Friday January 26, 2024 @04:54AM (#39140703)
>So that means you think microsoft should be allowed to force users to edge on windows ?

Arguably they're already doing that. There's a shockingly high number of times that I click on something in Windows and it opens up Edge instead of Firefox, my default browser. Even Apple manages to respect my default browser on macOS.

Re:BrowserEngineKit – Apple Developer Documentation by nolok on Friday January 26, 2024 @05:00AM (#39140760)
I agree, they're pushing hard toward that, our only saving grace being that they still must keep it decoupled at the low level due to existing regulation. The only thing that will stop them is some pushback, but threads like these scare me that the very people who should lead that pushback and now getting complacent to it ...

Whatever one might think about Chrome on desktop, fact are that 1 - people install it on purpose, because they want to, not because they're forced, and 2 - it's supremely easy to replace, which is why google tries hard to tie itself into more (password manager obviously, but chrome apps at one point).

Chrome is open to competition, it's just that this competition is as much marketing and mind share as it is tech merit. What Edge and Safari are doing or trying to do is not open to competition.

(this does not mean chrome should not be reigned it, I believe it should)

Re:BrowserEngineKit – Apple Developer Documentation by sureglymop on Friday January 26, 2024 @04:50AM (#39140667)
Why is that a guarantee? Of course, on Android I understand why people default to Chrome.

But regarding ios, at this point this is just speculation. Safari has the "default browser" advantage and people are used to it.

Re:BrowserEngineKit – Apple Developer Documentation by mort96 on Friday January 26, 2024 @05:02AM (#39140771)
Well, it's a guarantee that this change will give Chromium a higher market share on iOS, since the current market share of Chromium on iOS is exactly 0%.

How much of an effect it will have remains to be seen. But Google has shown themselves quite good at overcoming the default browser advantage by making other browsers not work well on Google websites and by pushing pop-ups into people's faces telling them to "upgrade" their browser to Chrome.

Re:BrowserEngineKit – Apple Developer Documentation by rvz on Friday January 26, 2024 @05:57AM (#39141222)
> Well, it's a guarantee that this change will give Chromium a higher market share on iOS, since the current market share of Chromium on iOS is exactly 0%.

Yes. Both the real browser engines in Chromium and Firefox are starting from absolute zero on iOS, and Chrome will certainly be much higher than Firefox.

Re:BrowserEngineKit – Apple Developer Documentation by Hamuko on Friday January 26, 2024 @04:47AM (#39140636)
Maybe Apple should just make good browsers if they want to compete, not just restrict people from installing other browsers.

I want to get a native Firefox iOS version if it means that I can get uBlock Origin on it. If I could get it on Mobile Safari, then I'd have basically no reason to download Firefox. But no, they'd rather not have me use it on desktop or mobile, since no version of Safari supports proper adblocking.

It's also a good time to remind people that the reason why you can't get a proper version of Firefox from the walled garden is because Apple explicitly doesn't allow Firefox to release it there. The walled garden very much prevents you from leaving it, and unwanted developers like Mozilla from entering it.

Re:BrowserEngineKit – Apple Developer Documentation by mort96 on Friday January 26, 2024 @04:50AM (#39140659)
Firefox, IMO, is a good browser.

It has laughably low market share.

Browser market share has very little to do with the quality of the browser after a certain point. Safari is a pretty good browser, but it has a decent market share due to Apple's policies. Google Chrome is a pretty good browser, but it has crazy market share because everyone uses Google services for everything and Google pushes Chrome incredibly hard, to the point of intentionally breaking their websites and/or arbitrarily disabling certain features in non-Chrome browsers.

Browsers don't really compete on their merits.

FWIW, I'm also looking forward to having proper Firefox on my phone.

Re:BrowserEngineKit – Apple Developer Documentation by roneythomas6 on Friday January 26, 2024 @06:47AM (#39141597)
Browsers do compete on merit. I use both iOS and Android. My Pixel 6 has an inferior processor compared to my iPhone 14. Even a 5 year old iPhone would smoke my Pixel 6 in benchmarks. But my day to day use Chrome on Pixel 6 is faster for JS heavy apps, scrolling and faster network loading. On a flaky network for sites with http3 the difference is day night between Safari and Chrome android. Chrome’s heuristics based rendering is far more advanced than Safari. I would say Safari a very good JS engine but Chrome has found other ways to make pages much faster.
Re:BrowserEngineKit – Apple Developer Documentation by mort96 on Friday January 26, 2024 @06:50AM (#39141607)
I'm happy that you have made what I'm sure is highly intelligent rational choices based solely on the technical merits of the browsers!

But there are significant factors outside of merit which influence popularity.

Re:BrowserEngineKit – Apple Developer Documentation by roneythomas6 on Friday January 26, 2024 @06:55AM (#39141635)
The thing is that Google has made Chrome really good that, there is less reasons for people to leave it for another browser. The only cons are privacy and fear of Chrome being the monopoly. I think other browsers should also compete on technical merits to stop haemorrhaging users.
Re:BrowserEngineKit – Apple Developer Documentation by mort96 on Friday January 26, 2024 @07:32AM (#39141924)
Yes, Chrome is good.

But there are significant factors outside of merit which influence popularity.