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.
