IOS 4.3 Nitro JS engine disabled for full screen apps and uiwebview
mobilexweb.com
mobilexweb.com
I'm sure it's a bug, but if it's not, it's not really a bad thing for Apple.
Perhaps Apple crippled UIWebView as some kind of plausible deniability, so that they could go about their evil ways. /s
Opera hasn't released its actual browser for iOS since doing so is banned by Apple's policies. Same for Mozilla. What they have released is Opera Mini which displays pages rendered by what is effectively a server-side browser.
So, it would not have make sense to slowdown UIWebView and accelerate Web Pages only for revenue point of view.
I think it is, as often, a interlaced tech-business issue:
1) Security: There might a genuin security concern the way the JIT works.
2) Exclusivity: I think Apple exec saw #1 as an opportunity to keep the performance gain as an exclusivity benefit for a while (Safari vs other browsers).
3) Developers: Apple's exec are probably realizing that there is a momentum starting to build around "Universal HTML5 Packaged apps," which would allow developers to decouple production from distribution. So, while they probably do not want to completely stop this momentum, slowing it a little might be seen as a good compromise for them.
Now, do not get me wrong, I am really disappointed at this news, and hope Apple will bring Nitro to UIWEbView soon.
In general I believe its good to not allow random bits of memory to become executable as it can easily introduce a large number of security and memory overflow vulnerabilities.
Perhaps as part of iOS 4.3, Apple has allowed Safari to circumvent this restriction but not any other application. Which would make sense because they control and are responsible for Safari, but to allow any application to circumvent this restriction could open iOS up to large security issues.
Given Safari is the biggest attack surface and regularly falls prey to exploits they should also disable the JIT for Safari. (Most iOS exploits like the Pwn2Own ones, and jailbreakme.com ones are due to bugs in Safari.)
A JIT works by compiling some chunk of code into a section of executable memory, then jumping to that location. As I understand it, iOS hasn't previously allowed execution of code from "data memory" (various people were curious about this very thing when it was announced they were shipping a JIT). Presumably, the Safari process has some special flag that allows it to write to executable memory, but most other processes do not. My guess is that someone forgot to add this flag to whatever application handles "full screen" pages, although maybe there is a legitimate reason for this.
Edit:
An example of the curiosity I mentioned: http://twitter.com/mraleph/status/43030240175468544
Perhaps you just meant the UI/web process separation itself, but it's interesting to note that Apple is going for a more general-purpose solution.
Benign explanation: some bug in safari
Tin foil hat explanation: Apple doesn't want web apps to be as good as native apps. This explanation kind of falls apart when you ask why they would bother boosting the js engine at all.
Non-fullscreen: 4094.5ms (test average) Fullscreen: 10528.2ms (test average)
I've re-done the tests for the iPad. Mobile Safari javascript is more than 2x as fast when run in the browser versus fullscreen mode.
Their exact motives will be revealed when they announce whether they plan to fix it or not.
Sure looks like a convenient bug though. In a sense, Microsoft probably didn't intentionally loose to other browsers with IE6, it was just very convenient for them to keep the entire web application ecosystem gimped for a few releases of Office...
However it should be noted most of the popular applications in the iOS app store are in fact games
The real reason is likely to be more to do with security around the js runtime, especially when UIWebView is placed in "wrapped" applications