[gte910h]

As people have seen to downvote this:

The reason why competing browsers aren't prevalent is that they don't want any executable code downloadable that isn't in their sandboxes.

Browsers have executable systems (Javascript, being the biggest issue), so they aren't allowed.

[shmerl]

By this logic any browser should be banned from the system, including their own, since their sandboxes have vulnerabilities as well. So I'm not buying this argument. Using security arguments to hide anti competitive intentions just doesn't cut it.

[gte910h]

It's not about vulnerabilities. It's a line in the sand that says "you can't have executable code in your app which is not signed and vetted before release".

They actually DON'T let you have the optimized javascript engine they use in their browser in your app either, probably for the same reason (security loopholes).

[shmerl]

The last time I checked their SDK license, it let you use their JavaScript VM for the dynamic code (unless this changed recently):

===> 3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded and used in an Application except for code that is interpreted and run by Apple's Published APIs and builtin interpreter(s). <===

So the argument that they ban any interpreted code is hypocritical. They ban competing browsers through banning JavaScript VMs.

[gte910h]

No, there is an optimized Javascript interpreter only in safari, then there is the UIWebView control which you can use a less-optimized javascript interpreter in your app.

http://www.quora.com/JavaScript/Why-has-Apple-limited-the-Ni...

Here is the why: http://daringfireball.net/2011/03/nitro_ios_43

>It’s a trade-off. Most OSes allow marking memory pages as executable for performance reasons. iOS disallows it for security reasons. If you allow for pages of memory to be escalated from writable to executable (even if you require the page be made permanently read-only first), then you are enabling the execution of unsigned native code. It breaks the chain of trust. Allowing remote code to execute locally turns every locally exploitable security flaw into a remotely exploitable one.

[shmerl]

Great, so they just know that there are more vulnerabilities in their own optimized engine, still they use it in their own browser. At the same time they ban anything else on the system, claiming that it promotes security. Doesn't sound convincing to me at all. Meaning, that if I, as user will find a more secure browser - I won't be able to use it, since it's banned on pretense that it'll compromise security (hypothetically, not that I use iOS as a user anyway).

[nirvana]

The entire premise of this thread is false. UIWebView uses the optimized engine as of iOS 5.

This is just an example of Apple releasing new code in the browser first before extending it into other apps being turned into an excuse for people to ignorantly or dishonestly bash Apple.

The reason it was put in Mobile Safari first is obvious-- Apple controls the source code there. Thus they can deal with any instability caused by the engine in the wild there.

If they immediately put it in all the UIWebViews in the system then many third party developers apps would become unstable due to these bugs.

I find it quite astounding that people are trying to make hay out of Apple using a phased roll out for a key piece of technology.

It just shows how any opportunity that can be used to mischaracterize Apple is seized upon, and even when the situation that led to the original issue is long resolved, people continue to report it as fact.