News for hackers. Stuff that matters.
Re:BrowserEngineKit – Apple Developer Documentation by nolok on Friday January 26, 2024 @04:27AM (#39140506)
Finally firefox + extensions will be able to reach ios.

I find it a bit puzzling and amusing how so many people in the other threads are acting like this is the end of safety on apple and yada yada, while 1 - you're free to stay well within the walled garden if you so desire, stepping out is a personal choice (but now is a choice for the user, instead of banning him from doing something apple doesn't like), 2 - we have the example of android to know apps won't each flock to their own little store, 3 - the whole pretense of "the curating of the store allows them to ensure high quality safety" is frankly not in line with reality, the app store being full of crap and spam while blocking updates to apps that apple don't like (spotify for example).

I'm flabbergasted at "tech oriented users" ability to forget what they know when it come to certain brands they like.

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.

Re:BrowserEngineKit – Apple Developer Documentation by coldtea on Friday January 26, 2024 @06:37AM (#39141515)
>you're free to stay well within the walled garden if you so desire, stepping out is a personal choice

Not if Chrome gets a huge mobile web broswer share and you end up needing to use it for compatibility.

Or if major third party apps that you want to use (say Facebook or YouTube or whatever) are all moving into their vendor's app stores.

>the whole pretense of "the curating of the store allows them to ensure high quality safety" is frankly not in line with reality, the app store being full of crap and spam while blocking updates to apps that apple don't like (spotify for example).

I don't think it is. It might not have only top tier apps, but it's not full of spam and crap the way the Android store is, and has a much smaller problem with malware.

Just because the bad apps aren't reduced to 0% compared to Android, doesn't mean a 50-80% reduction is not already a good thing.

As the "tech guy", I routinely have to uninstall slow crap stuff that hogs down the whole phone from parents and friends Android phones. iOS? Not so much, if ever.

Re:BrowserEngineKit – Apple Developer Documentation by trollsund on Friday January 26, 2024 @06:46AM (#39141586)
> Or if major third party apps that you want to use (say Facebook or YouTube or whatever) are all moving into their vendor's app stores.

The major third party apps are still on Google Play though, why should they act any differently on iOS?

Your point on Chrome is indeed an issue, and I am pessimistic. While Firefox has a browser engine, how many can they spare to port/retrofit it for iOS?

Re:BrowserEngineKit – Apple Developer Documentation by lern_too_spel on Friday January 26, 2024 @11:04PM (#39152419)
> I routinely have to uninstall slow crap stuff that hogs down the whole phone from parents and friends Android phones. iOS? Not so much, if ever.

Your Android parents and friends are lucky. They are at least able to easily uninstall slow crap stuff from their phones. You cannot uninstall slow crap Safari from an iPhone.

Re:BrowserEngineKit – Apple Developer Documentation by coldtea on Monday January 29, 2024 @08:19AM (#39175878)
>You cannot uninstall slow crap Safari from an iPhone.

Which is irrelevant. You can always not use it. And when you don't use it, it doesn't slow down your iPhone.

In fact it doesn't slow down your iPhone even when you use it.

In Safari's backend is close up there with Chrome for speed and beats Firefox (as seen in macOS, where all three engines are available). It also does so with much less memory and cpu load, to the point that it adds 20% or more of battery life to use it on a laptop.

Re:BrowserEngineKit – Apple Developer Documentation by lern_too_spel on Monday January 29, 2024 @10:35AM (#39177435)
> You can always not use it.

Apple forces all other browsers to be equally slow.

> it adds 20% or more of battery life to use it on a laptop.

This hasn't been true for years.

Re:BrowserEngineKit – Apple Developer Documentation by rmccue on Friday January 26, 2024 @05:40AM (#39141082)
> stepping out is a personal choice (but now is a choice for the user, instead of banning him from doing something apple doesn't like)

The choice is the developer's not the user's, if the app is only available in one app store (which seems likely to be the majority case).

Precisely because it is the developer's choice, users may be forced to leave the safety of the walled garden if they need an app that's not available - I saw another HN comment phrase it well as: if an app you need in order to "survive" is not available, you don't have a choice (for example, a banking app or a government app).

Re:BrowserEngineKit – Apple Developer Documentation by jonbell on Friday January 26, 2024 @04:30AM (#39140531)
1) More spam on Android by far 2) Spotify not blocked

There’s a bit of religion happening in both directions. iOS has, objectively, fewer problems than Android in these regards and part of that are the policies.

Re:BrowserEngineKit – Apple Developer Documentation by seszett on Friday January 26, 2024 @04:43AM (#39140610)
What do you mean by "spam on Android" though?

I don't get spam on my phone (well, SMS spam sometimes but that has nothing to do with the OS) and nobody I know does. Also, I keep hearing on HN that iOS doesn't split notifications into channels and you can't block just the ad notifications. Unlike on Android where I block the ads for Uber Eats, the only application that wants to spam me (but doesn't, since I can just disable ads).

Re:BrowserEngineKit – Apple Developer Documentation by khazhoux on Friday January 26, 2024 @04:45AM (#39140617)
App store spam
Re:BrowserEngineKit – Apple Developer Documentation by d3w4s9 on Friday January 26, 2024 @07:36AM (#39141957)
If you think "app store spam" is a real thing, you've spent way too much time on app store.

I install apps that I need -- news, banking, podcast, email, Uber etc, usually from well known companies. A small amount of apps are lesser known but they have good reviews.

I don't think there is any fundamental difference from the Apple app store. Maybe do a check of yourself first.

Re:BrowserEngineKit – Apple Developer Documentation by mort96 on Friday January 26, 2024 @05:43AM (#39141104)
I think this would be a better argument if Apple wasn't so careless with what they accept on the App Store. There are scam apps, apps which try to trick users into accepting subscriptions, tonnes and tonnes of "casino for children" games, games which clearly try to trick children into spending their parents' money, etc.
Re:BrowserEngineKit – Apple Developer Documentation by repox on Friday January 26, 2024 @04:33AM (#39140546)
> There’s a bit of religion happening in both directions. iOS has, objectively, fewer problems than Android in these regards and part of that are the policies.

When you say "objectively" I assume that this is something that has been measured and that there are reliable sources for this statement?

Re:BrowserEngineKit – Apple Developer Documentation by ruszki on Friday January 26, 2024 @05:09AM (#39140832)
I would be really surprised. Anytime when I’ve searched for a feature (like DLNA sharing), and not for a specific app, I’ve got only very shitty spam apps in both stores. Even when I search for specific app, like GTA, the results deteriorate very quickly, in both stores.
Re:BrowserEngineKit – Apple Developer Documentation by nolok on Friday January 26, 2024 @04:45AM (#39140621)
The moment there are more than a very minimal / virtually non existing amount of spam and scam, it doesn't matter who has more, whatever control are in place don't work, at least not to the extant of "you must make massive concession to your rights on your own device to ensure we can do that".

That is my point of view, and to each their own I assume.

As for Spotify, yes technically it's not blocked, probably because they know that's a line they can't cross.

> iOS has, objectively, fewer problems than Android in these regards

You really need to outline clearly what "regards" you mean in that front, and objectively implies fact backed. I would disagree with that statement as-is.

Re:BrowserEngineKit – Apple Developer Documentation by poisonborz on Friday January 26, 2024 @04:43AM (#39140608)
iOS has a fraction of the userbase and developer activity of Android globally, which affects also the US market, from where it might seem dominant.
Re:BrowserEngineKit – Apple Developer Documentation by rvz on Friday January 26, 2024 @06:05AM (#39141272)
No wonder that explains the amount of ransomware garbage on Android devices out there: [0] and it is more prevalent on Android than iOS. [1]

[0] https://www.cloudsek.com/threatintelligence/copy-of-malware-...

[1] https://www.helpnetsecurity.com/2023/09/22/apps-attack-risk

Re:BrowserEngineKit – Apple Developer Documentation by amusingimpala75 on Friday January 26, 2024 @07:12AM (#39141788)
Orion + FF or Chrome extensions already exists for iOS, implementing the extension interfaces on top of WebKit. Which part is the one you want, the extensions or Firefox? ‘Cause if you just want uBO on iOS you already can.
Re:BrowserEngineKit – Apple Developer Documentation by secretsatan on Friday January 26, 2024 @05:03AM (#39140779)
It's the risk of attack through a sidechannel, the ability to install something on your phone, not just through leaving your phone attended, but social engineering etc.

As an example of where your android example is worrying, stalker apps are currently only available for Android.

I was always of the opinion that if you didn't like the walled garden, don't buy apple. That's also a choice. It looks like this was a successful startegy on apple's part, and people want to muscle in.

Re:BrowserEngineKit – Apple Developer Documentation by nolok on Friday January 26, 2024 @05:08AM (#39140822)
What you're saying is "If you don't like the walled garden, don't buy john deere", essentially.

When a product start becoming such an important part of its owner life, and has such a huge market share, I believe society should impose some rules on it to ensure it conforms with the ideals of said society. In this case, ability to be in control your non niche computing device.

So I think this is a case where we must agree to disagree.

Re:BrowserEngineKit – Apple Developer Documentation by secretsatan on Friday January 26, 2024 @05:26AM (#39140993)
`When a product start becoming such an important part of its owner life, and has such a huge market share, I believe society should impose some rules on it to ensure it conforms with the ideals of said society. In this case, ability to be in control your non niche computing device.`

But people buy them because of the restriction that you don't like. you're imposing your own standard on something you probably wouldn't even buy. I doubt most users give one single thought to rooting their phone

Re:BrowserEngineKit – Apple Developer Documentation by nolok on Friday January 26, 2024 @05:34AM (#39141046)
> But people buy them because of the restriction that you don't like

You will need a source that people buy them because of the restriction.

> you're imposing your own standard

No, our EU society has done so, through our elected parliament.

> I doubt most users give one single thought to rooting their phone

This subject has nothing to do with rooting a phone.

Re:BrowserEngineKit – Apple Developer Documentation by cqqxo4zV46cp on Friday January 26, 2024 @06:53AM (#39141620)
I do.

There you go.

Now you can argue with more nuance than “users are being held hostage!”

Re:BrowserEngineKit – Apple Developer Documentation by nolok on Friday January 26, 2024 @09:03AM (#39142668)
Yes you do, and others do not, which is why my point was society at large while you said "users".

I did not say nor imply what you put in quote, you chose to read that which is different.

Re:BrowserEngineKit – Apple Developer Documentation by Hamuko on Friday January 26, 2024 @06:02AM (#39141254)
"Because" or "despite"? Because I don't remember anyone ever saying that they prefer iOS because it only has Safari on it.
Re:BrowserEngineKit – Apple Developer Documentation by d3w4s9 on Friday January 26, 2024 @07:32AM (#39141923)
Reading many of the sibling comments just makes me laugh.

Android has allowed everything from the beginning, and overall it looks... fine? Of course there are all kinds of malicious actors who manage to publish malware on Play Store or trick people into sideloading, but if my mom, a basic Android user who knows very little about how computers and phones work, never got herself into trouble, that says something. You must be either dumb enough or really understand exactly what you are doing to go way out of the safe zone to download a shady app.

And anyone concerned about browser's safety -- if that were a real thing we'd have already been screwed on Windows and Mac. The reality is that most people use Chrome and it is generally safe enough for everyday use. Some people use Firefox, Brave and whatever but most of those are well maintained. If you install a browser that nobody knows, that's your problem.

This is just all fear mongering. So stupid.

Re:BrowserEngineKit – Apple Developer Documentation by d3w4s9 on Friday January 26, 2024 @07:32AM (#39141922)
Reading many of the sibling comments just makes me laugh.

Android has allowed everything from the beginning, and overall it looks... fine? Of course there are all kinds of malicious actors who manage to publish malware on Play Store or trick people into sideloading, but if my mom, a basic Android user who knows very little about how computers and phones work, never got herself into trouble, that says something. You must be either dumb enough or really understand exactly what you are doing to go way out of the safe zone to download a shady app.

And anyone concerned about browser's safety -- if that were a real thing we'd have already been screwed on Windows and Mac. The reality is that most people use Chrome and it is generally safe enough for everyday use. Some people use Firefox, Brave and whatever but most of those are well maintained. If you install a browser that nobody knows, that's your problem.

This is just all fear mongering. So stupid.

Re:BrowserEngineKit – Apple Developer Documentation by cqqxo4zV46cp on Friday January 26, 2024 @06:52AM (#39141616)
Anyone that’s actually listening to the other side of this conversation would already know what responses to expect from what you’ve said. By saying what you’re saying you’re really making out like you only seek to throw your opinion over the fence and walk off. There are legitimate cases to be made on both sides, but your comment is not one. Calling this clear a win for user choice is naive and frankly a tad self-centred. For the average iPhone user, a user that mind you realistically wasn’t asking anything of their device that was being stopped by Apple’s rules, realistically has more to lose here than they do to gain. Who the hell uses browser extensions in 2023 let alone ones that weren’t already available in Mobile Safari?

This is above all a “win” for companies like Meta who will use their market power to create a more user-hostile experience for the common user. I don’t care if you don’t use Facebook anymore because you don’t like it. The reality is that a lot of people do, and the restrictions put in place by iOS definitely stop the Facebook app from being as bad as Meta would like it to. Now all it’s going to take is Meta to say “Instagram is only available on the Meta store”, or some variant thereof, for things to get a whole lot worse, quickly.

Delusional indie developers see this as a win when in reality it was hard enough to get people to use their apps in the first place.

Just as delusional are the tech enthusiasts that have along the way somehow conflated “cool new iOS features that I’m going to spend some time geeking out over” with “something that will legitimately make the experience better for end users at large”.

Above all, the view that anyone that disagrees with you isn’t a smart utility-belt-wearing techie such as yourself is such an absurd hill to die on and avenue to assert your elitism. I’ve spent considerable time using Android devices and customised them out the wazoo. I know how computers work. Gentoo was my daily driver for a long time. I grew up obsessed with computers and everyone around me knew it. By any of the silly tribal measures that I’m sure you’d use to establish who is a “real nerd”, I’m probably going to quality. Please consider that the fact that you can’t comprehend why supposedly smart people disagree with you may be a sign that you aren’t interrogating your own view enough, rather than it being a sign that you’re the only sane person in a world going insane.

Re:BrowserEngineKit – Apple Developer Documentation by d3w4s9 on Friday January 26, 2024 @07:40AM (#39141988)
You might want to check out the Firefox add-on (extension) store for Android before posting such uninformed comments.
Re:BrowserEngineKit – Apple Developer Documentation by merrywhether on Friday January 26, 2024 @08:39AM (#39142470)
> choice for the user

I find it ironic when this is framed as user choice when it is being lobbied by massive corporate interests for their own benefit.

Epic wants to give you the “choice” to download Fortnite from exactly one place, forcing you to install their App Store if you want to engage in that fairly important social network.

Google wants to give you the “choice” to help create total Chrome hegemony, giving them an absolute monopoly on web tracking once they disable 3P cookies this year. Is the DMA going to step in there and give users the choice to configure their tracking engine in that monopolistic market?

How many recursions of choice will DMA protect? Or was there already choice in the form of Android as people continually point out?