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.
Full screen web applications launched from your home screen in iOS 4.3 run slower than when they were run inside mobile Safari. It turns out that web applications that run from the homescreen do not use the new Nitro JavaScript engine, while Mobile Safari does. Nitro plays a large role in the browser speed-up between iOS 4.2 and 4.3.
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.
What?! The Register talking out of their ass – wow, that’s gotta be a first *rolls eyes*
Come on, really, the number of people citing The Register article as some sort of ‘final say’ when it comes to all things related to IT makes me cringe. The Register is little more than a glorified set of Slashdot posts being paraded as articles with the comments section being no better than clicking onto a Glenn Beck/O’Reilly fan forum (if such an entity exists).
The forum itself is a massive echo-chamber where the moderators only allow the views they agree with being approved before being posted. I’ve signed up and posted a couple of replies (in the comments section) pointing out where the article writers were incorrect (in a polite way) and found that my comments are never accepted – god forbid someone actually writing a constructive critique of where the article went wrong!
Edited 2011-03-18 23:50 UTC
The article, as it stands now anyway, is accurate. It has a typically sensationalist bent, but the facts given match the osnews article.
LOL, I haven’t read that site in years for this very reason. Sad to see they apparently haven’t changed at all.
When Mozilla created first TraceMonkey, and then JaegerMonkey, they had to disable it for the JavaScript used in Firefox’s chrome because that load of code was not programmed with JIT in mind since it used a wider set of APIs than vanilla JS and communicated with XPCOM components and C-interfaces. Firefox 4 now ships with it all switched on.
I see this as similar for the Apple situation. Running web code is one thing, but JavaScript used in WebUIViews in third party apps could be doing anything beyond the scope of typical JavaScript. What’s more since JIT allows for a form of memory (of sorts), this could be used as a new, effective form of jailbreaking. Just add a web-page to your home screen and then run it — the context changes because the code is no longer running inside Safari, but as its own app outside Safari.
We’ll just have to wait and see what the next update from Apple does.
I’ve just been writing what’s essentially an HTML5/JS/CSS3 app that runs inside a UIWebView on the iPad. The JS environment that you get inside UIWebView is essentially identical to what you will find inside MobileSafari. It cannot inherently do anything “beyond the scope of typical JavaScript”.
There are two things available to help interaction between the UIWebView/JavaScript and native/ObjC environments:
* UIWebView provides stringByEvaluatingJavaScriptFromString, allowing native code to interact with the JS environment.
* UIWebViewDelegate provides shouldStartLoadWithRequest which allows URL requests to be intercepted by your ObjC code, allowing JS to trigger native actions.
This division ensures that the JS code can’t do anything native directly. So technically the JS code doesn’t do anything beyond the scope of typical JS, and thus this isn’t quite the same situation as Firefox had.
As has been identified, the real problem Apple has is the security model of iOS. Processes can’t arbitrarily mark code pages as being executable but as the JIT in Nitro requires this an exception is made for MobileSafari. Allowing any app using UIWebView to do this would allow them to download arbitrary binaries over the ‘net and executed – a serious breach of the current security model.
WebKit2 allows for a Nitro JIT-enabled process, with arbitrary code execution enabled, to run alongside a regular app process running with the existing security restrictions. The UIWebView API can stay the same as it is right now, so existing apps would continue to work just fine.
> iOS, however, does not allow memory pages to be marked as executable.
If that was the case, it won’t be able to execute any code. iOS doesn’t allow making *writeable* pages executable.
> UIWebView they did not make this exception. It would defeat the purpose of the App Store review process.
How so? The only C code that runs there is Apple’s C code. You can run the very same app from Safari with JIT.
The reason probably is that exception for Safari is a quick hack, and Apple didn’t want to do this for anything else.