I'm not super concerned about that. In particular, no such browser exists, so it's largely a semantic argument.
Furthermore, there are inherent security risks; so it's easier to just lock it down until there is actually a problem.
The bigger problem is that you can't implement a JIT on iOS, because you can't take a writeable page and make it executable. This is a clear security positive for iOS, but does preclude writing a decent javascript runtime.
Not quite. I did consider Servo, but it's hardly ready for use in the wild. It'd fall foul of many iOS guidelines, not just the 'no browser' one.
It'd also fall foul of the 'only C, C++, Objective-C, Swift' guideline, for example.
I didn't know the second point, but it's clearly there for the same reason; it's an easy way to stop apps from including new functionality and bypassing the review process.
Sure, I understand why they have the interpreter rule in place. It just blocks legitimate apps and reduces competition with Apple's products, which is what blumkvist is asking for an example of.
And I wasn't talking specifically about their "no browser" or "no interpreter" guideline, just the sum total of requirements they have for iOS apps. The actual details of which exact requirement block useful things are not that important for purposes of addressing blumkvist's original question, which was how Apple's policies are more restrictive than those of Microsoft 20 years ago in ways that block objectively useful things.
Furthermore, there are inherent security risks; so it's easier to just lock it down until there is actually a problem.
The bigger problem is that you can't implement a JIT on iOS, because you can't take a writeable page and make it executable. This is a clear security positive for iOS, but does preclude writing a decent javascript runtime.