The past few days have seen a stink regarding web applications on iOS. El Reg ran a story about how web applications launched from iOS’ homescreen ran significantly slower than when ran inside mobile Safari. As more details emerged, it became clear this wasn’t a deliberate move by Apple – but rather an implementation issue.
The issue here stems from the fact that Nitro is a just-in-time-compiler, and therefore, requires memory pages to be marked as executable. iOS, however, does not allow memory pages to be marked as executable. For Safari, Apple apparently made an exception – but for Web.app (which is what full screen web applications use when run from the home screen) and third-party applications that use UIWebView they did not make this exception. It would defeat the purpose of the App Store review process.
You could, of course, conclude that Apple did this on purpose to harm web applications, to push developers to make native applications. However, this makes no sense since App Store applications that use UIWebView don’t get Nitro either.
It makes much more sense to see the exception for mobile Safari as a temporary measure until WebKit2 is ready. WebKit2 will integrate the slit-process model into the very bowels of the rendering engine, which would enable Apple to run Nitro in its own trusted process so that any application can make us of it.
So, this seems to be much ado about nothing. Nitro makes mobile Safari faster – it doesn’t make anything else run slower.