> To help keep users safe online, Apple will only authorize developers to implement alternative browser engines after meeting specific criteria and committing to a number of ongoing privacy and security requirements, including timely security updates to address emerging threats and vulnerabilities.
This criteria seems arbitrary. Doesn't this allow Apple to arbitrarily prevent competitor engines like Blink and Gecko?
In short, browsers will have higher privileges that normal apps, as they can execute arbitrary code in memory, so they are naturally held to a higher standard.
To be honest I am happy about this. I don't trust a random banking / government / public transport app contracted out to the lowest bidder to be safe from all buffer overflows or other memory safety issues, so making sure they are sandboxed away from executing arbitrary code is a good thing.
No more than any other app. It runs anyway in the app sandbox, and can only access the resources that are accessible from the app sandbox itself. For the application to gain root privileges it would need to exploit a flaw in the sandbox itself, something difficult these days.
Android allows applications to map memory pages as executable (in fact you can also launch any Linux executable as a subprocess) and there was never an issue about security: if you don't have a rooted phone you don't have chances to get code running as root, since everything runs in the app container.
And if there is a flaw that allows escaping from the app sandbox, it can probably be exploited without being able to map memory pages as executable anyway, since it will probably be a flaw in a kernel system call or library function.
So really: this was always a limitation that Apple did impose to not allow in practice competing browsers in the Apple store, since a browser to be efficient this day needs to compile code as JIT, as well as not allowing applications that benefit for JIT execution (such as emulators or compilers).
And this seems understandable to prevent a proliferation of 100's of "browsers" trying to steal your data. You actually have to be developing something legit -- not just reskinning a browser engine and leaving it.
You can already do that today (yes, on iOS) by using your own developer-signing certificate (because if it's from github, you can build it from source; or re-link/assembly prebuilt linkable binaries if you really feel like it).
Remember the vast, vast majority of iOS users are people like (I assume) our parents - or people we knew in the late-1990s/early-2000s with an excessive number of Internet Explorer toolbars and Bonzi Buddy. I support Apple's mission to keep crap like that off their platform, but Apple sleepwalked into prompting this regulation of their app-store because they weren't the good-stewards they said they'd be - so I'm ambivalent about the whole thing.
“I should be allowed to…” will always reek of entitlement. Pick your hardware and platform on your likes and needs. There are plenty of options to choose from.
I think what would be helpful if there was a concept of a "system admin" profile that you could apply onto any device/computer. Non-technical users may want Apple to be the 'sysadmin' and only use the Apple store, use Apple recommended apps, etc. - Kinda like the an MDM profile.
Any other vendor, as a paid/managed service, could supply a more permissive app store, and manage updates, etc. Companies who issue work devices would have their own "profile" to manage the device.
On the other hand they will likely use this to deny all ‘niche’ browser engine without a structured organization behind them (think Ladybug, maybe servo etc.)
https://webkit.org/blog/14787/webkit-features-in-safari-17-2...
Yes, not as frequent as monthly releases, but Apple shipped 7 Safari updates on iOS in 2023.
https://webkit.org/blog/13691/webkit-features-in-safari-16-3...
https://webkit.org/blog/13966/webkit-features-in-safari-16-4...
https://webkit.org/blog/14154/webkit-features-in-safari-16-5...
https://webkit.org/blog/14416/webkit-features-in-safari-16-6...
https://webkit.org/blog/14445/webkit-features-in-safari-17-0...
https://webkit.org/blog/14735/webkit-features-in-safari-17-1...
https://webkit.org/blog/14787/webkit-features-in-safari-17-2...
Did you notice the new Safari 17.3 Apple shipped 3 days ago?
These requirements are things like "Use memory-safe programming languages", "Adopt the latest security mitigations", if you ship your own certificate trust you should "provide information on how a root certificate authority (CA) can apply to become part of the program".
All seems like pretty basic conditions designed to ensure that only Mozilla and Google can comply.
To be honest, the browser engine stuff seems significantly more robust and permissive that I was expecting.
I wonder if Apple would be allowed to ship WebKit if they enforce this requirement under the spirit of the EU laws that made them change their minds.
> Use memory-safe programming languages, or features that improve memory safety within other languages, within the Alternative Web Browser Engine at a minimum for all code that processes web content
Emphasis added.
Why is it any of Apple's business how many test suites a third party browser can pass?
Why can't iPhone users run Links if they want to? Why can't they run a browser without Javascript support? Why can't they try out Ladybird to see how development is progressing?
Like, even from a pure Apple-is-greedy perspective I don't understand the point of this.
In the end it's not a big impact on apples revenue if some people run chrome or Firefox.
The store part on the other hand is really sketchy.
That's the point, but they sound nice
