Linked by Thom Holwerda on Fri 18th Mar 2011 18:26 UTC
Apple 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.
Permalink for comment 466882
To read all comments associated with this story, please click here.
RE: Comment by Kroc
by steve_s on Sat 19th Mar 2011 12:24 UTC in reply to "Comment by Kroc"
Member since:

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.

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.

Reply Parent Score: 2