The issue affects UIWebView, which means it affects native apps too. Not quite to the same extent, naturally, but the issue is there.

Perhaps Apple crippled UIWebView as some kind of plausible deniability, so that they could go about their evil ways. /s

Well, not really. Web Apps are faster, it is the "packaged apps" using a UIWebView that did not gain anything, and Apple is getting 30% of those as well.

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.

Missing the point. Apple doesn't and can't control web apps that are outside the App Store. They can control what goes into the App Store. Preventing web apps from performing on par with native apps will discourage development outside their controlled app store. I'm not saying that Apple is doing this, just that the conspiracy theory does make sense and even has prior art (see Microsoft and IE6)

web apps on home page and apps wrapped web components which still use html, js etc are punished. so it is not a conspiracy, it is a bug but if it is intentional by apple; it is a faux pas. welcome to ie6 in ios; intentional punishment of web apps to cut itunes cannibalization.