UIWebView is slower for security reasons. (Non-Apple) Apps aren't allowed to mark memory as an executable code space, which JITs require. Perhaps there would be some way for Apple to solve that for Nitro without introducing security concerns for all apps, but I'm not convinced.
I much prefer knowing apps can't surreptitiously create new executable parts of themselves.
I don't understand why they can't sandbox the UIWebView. That's how mobile Safari (presumably) is secured, as is Chrome. It has to render/execute untrusted content in any case.
Performance, probably. To sandbox it I imagine it would have to run in a separate process, and then you'd have to pass messages back and forth, which might be slow. But who knows.
It may be one of these things they were planning to do later, and then someone pointed out it would possibly be detrimental to what they want the iOS ecosystem to be, so they scrapped plans.
Message passing between a UIWebView is already one of the big complaints, requiring slow and klunky workarounds. To receive a message you detect URL anchor (#foo) changes in objective C. Sending is a bit better (inject a js string).
I wonder if its possible to sandbox a thread as opposed to a separate process. I doubt that Apple consciously neglects HTML5 app SDK functions. iOS has been the best platform for HTML5 for a couple of years already, supporting features (CSS 3d for one) that Android didn't.
They "have to"? I was under the impression that you had a choice of UIWebView and your own custom implementation. Are they really going to block sales of an app if it has an alternative JS engine?
You might be able to do your own JavaScript implementation, not sure, but I think actually not. (I stand corrected on this). But V8 definitely won't be permitted under the current laws, as it uses executable blocks of code in memory, which are not permitted, for security reasons under iOS.
Don't see that rule changing. Let's hope Apple let other browsers be the default though.
No, Apple's iOS developer agreements do not allow browsers with their own JavaScript engines:
"Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework."
Isn't UIWebView a component written by Apple? Why not include Nitro in it? Why would it be a security issue on Chrome but not on Safari? Do people have access to the UIWebView source code? If not, this "security" reason is BS.
Third-party processes on iOS cannot mark data pages as executable, which is a great security feature but it prevents JIT compilers or any other technology that dynamically generates machine code. Apple's built-in apps have an exception to this security mechanism, presumably because Apple is more confident in their own security auditing of those apps. Perhaps with some sandboxing mechanism and/or code auditing process they could allow some third-party apps similar access in the future, but it's not clear whether they feel a need to.
The restriction on executable pages is enforced by the kernel at the process level. This particular mechanism won't allow for enforcing diffeerent policiees for UIWebView code running in the same process as app code. If UIWebView could run JavaScript code in a separate process like Chrome then it might be possible.
