[BoppreH]

The other requirements are also pretty vague and give Apple full discretion to remove browsers they don't like:

https://developer.apple.com/support/alternative-browser-engi...

> 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;

> Adopt the latest security mitigations (for example, Pointer Authentication Codes) that remove classes of vulnerabilities or make it much harder to develop an exploit chain;

These allow Apple to take a security-maximalist approach and block alternative browsers that don't include the most performance-killing mitigations possible.

I don't think these points are bad per-se, but within the context of malicious compliance that Apple has already displayed, I'd be scared to invest money on alternative browser for iOS.

[ComputerGuru]

Why do I have a sneaky feeling Safari for iOS isn’t fully written in a fully memory safe language?

[saghm]

"We're smart enough to safely use these languages but you're not" is a bold claim that just happens to end up with the exact same consequences of their earlier rule that was deemed anticompetitive, there's no conspiracy here!

[glandium]

For instance, rust doesn't support PAC yet https://github.com/rust-lang/rust/issues/73628. Support for PAC wasn't even in upstream LLVM for a while (it now is, but lld still doesn't support it).