> When has Apple hindered a break-through technology?
Contemporary example: it's impossible (as in, disallowed by Apple's policies) to install a web browser with a rendering engine written in a memory-safe language on your iDevice.
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.
I'm genuinely interested. I'm not a developer and don't know what that means. It sounds bad, but how does it stifle competition? Is Safari gaining an advantage? I used Chrome on my iphone4 and was pretty happy with it.
Chrome on iPhone is forced to use Apple's rendering engine, not Google's. In particular, it can't implement any HTML/CSS/JS features that Safari on iPhone doesn't implement.
Apple benefits partially in terms of disallowing possibly-unsafe code (JS interpreters, for example) that they themselves did not author. But also from locking out competing browsers so their hardware is harder to commoditize...
In terms of stifling competition, it means there isn't meaningful competition on iOS in terms of features browsers expose to web pages. Browsers on iOS can have different user interfaces, but they all look more or less identical as far as web pages are concerned. (I say more or less because browsers can implement a custom network stack; just not a custom CSS parser or JS engine.)
So for example, if you want a browser on iOS that supports the "transform" CSS property without the "-webkit" prefix, you're out of luck. Apple's policies don't allow such a browser. This is not "break-through technology", of course. But a browser engine in a memory-safe language, with the resulting smaller attack surface, is. And it's disallowed by Apple.
To answer your own question, it's stifling competition in the iOS browser space. The above example is precisely why Firefox (for example) is unavailable on iOS; they didn't want to make a technical compromise like using Apple's version of WebKit instead of Gecko or (eventually) Servo.
Basically, the only browsers allowed on iOS are reskins of Safari. Technical competition is stifled that way.
Chroms of iOS is a re-skinned Safari WebView[1]. They just put a front-end on it with their added on features. Apple entirely controls the browser and what's allowed, disallowed, supported, etc. For example, Google's SPDY protocol wasn't supported until Safari 8[2], and probably then because much of what SPDY entailed was adopted as HTTP/2.
Contemporary example: it's impossible (as in, disallowed by Apple's policies) to install a web browser with a rendering engine written in a memory-safe language on your iDevice.