> 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
Would Apple themselves meet this requirement? Isn't WebKit C++? Of course, I'm not sure what would be considered "features that improve memory safety within other languages," that's kind of vague.
So any language should be allowed as long as they instruct developers to be careful.
I am sure that Apple will make no other efforts to impede others from unwalling the garden. That would be completely ridiculous, and frankly, un-Apple-esque.
There is absolutely zero way to satisfy the latter part here. It's at best non-enforceable. If I'm using C++ and use std::span instead of a c-style array, is that good enough?
It doesn’t say that it needs to provide absolute memory safety. Based on the linked WebKit guidelines, it seems like they meet the criteria.
My point is the requirement is too broad. It cannot be meaningfully enforced.
https://developer.apple.com/support/alternative-browser-engi...
You have to request explicit permission to be able to be a browser on iOS. You can’t just ship an app. I assume part of that process is that you specifically demonstrate that you try your best to use best safety practices.
Again, it’s also not absolute safety. It’s just due diligence review.
> 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;
This can't be analyzed in any real way, so its just another way that Apple will restrict web engines and claim it was due to "not enough use of memory safety language features"
There’s a lot of things in the requirements like funding that Apple cannot verify. I think you’re being too binary in this.
Some of it is very clearly intended to be a “show us you are at least considering these security measures and have practices in place to minimize known issues”. Again, for the third time, it’s clearly NOT a list for ongoing perfect security, given that there are other items on the list that deal with further mitigation strategies.
This is meaningless. Apple can carve out special exceptions for themselves all day long.
This is literally the question I started this thread with and you have gone in to a loop of saying “they can’t enforce this” without any response of substance.
If you are going to make guidelines, make them evaluable. These aren't. If you care about memory safety, either say use a memory safe language or point to an exact reference guide to use to allow XYZ language to satisfy it.
If you would pause for a second and actually read the rules in their entirety it is obvious that the lines you’re fixating on aren’t meant to be absolute security measures and therefore don’t need to be continuously evaluated.
Your conjecture about Apple withholding the permissions for arbitrary reasons is not borne out of evidence. When asked REPEATEDLY to show where they’re giving themselves an exception to their own rules, you continuously fail to provide any example and are just hand waiving conjectures.
Maybe they are doing what you’re saying but you’re making an incredibly poor argument regarding it.
And heres a nice video about it: https://youtu.be/Gv4sDL9Ljww?si=Z4riPMKAKcIKaU0s