6 ms·

They might be able to handle it with a remote view controller. An existing iOS technology that allows for a view controller that fronts an out-of-process applic

• eridius 12y ago
  That's quite unrelated. That's a technology that allows for e.g. the Mail compose screen to run out-of-process while still compositing into the same layer hierarchy as the host application and receiving touches. This not only allows restricting access to Mail accounts to the daemon that runs the remote controller, but also prevents the host application from doing things like hiding the mail compose controller behind another view and forwarding touches to it, so a press on an unrelated button actually triggers an email send. WebKit2 is done differently. The UIWebView still handles all the user interaction and whatnot, and it talks to the Web Process to send it requests (e.g. "load this URL", "run this JavaScript in the context of the page", etc). I'm not quite sure how the compositing of the web content works, but it's not the same system as remote view controllers.
  • 0x0 12y ago
    There's stuff here about a UIRemoteWebViewController: http://oleb.net/blog/2012/10/more-on-remote-view-controllers/ http://oleb.net/blog/2012/10/more-on-remote-view-controllers... https://github.com/nst/iOS-Runtime-Headers/blob/master/Frameworks/UIKit.framework/_UIRemoteWebViewController.h https://github.com/nst/iOS-Runtime-Headers/blob/master/Frame... https://github.com/nst/iOS-Runtime-Headers/blob/master/Frameworks/UIKit.framework/_UIServiceWebViewController.h https://github.com/nst/iOS-Runtime-Headers/blob/master/Frame...
    • eridius 12y ago
      Possibly interesting information, but still not actually relevant to WebKit2.
      • dunham 12y ago
        I might not have been clear in my grandparent post. I wasn't proposing this as a means to WebKit2. (I don't know what WebKit2 is.) I was suggesting this might be a way to get JIT support in native apps with the current iOS WebKit, by running the entire UIWebKit out of process. However, I have no idea if there are enough hybrid apps out there, with javascript performance issues, to justify going to the trouble of doing this.
        • eridius 12y ago
          Ah. Well, it's a cute idea, but it won't work with UIWebView. Besides the fact that existing apps already rely on the fact that UIWebView isn't remote (because they can muck about with various view properties of it, including direct access to its UIScrollView), UIWebView also exposes at least one synchronous API (-stringByEvaluatingJavaScriptFromString:) and synchronous APIs are no good when doing stuff out-of-process. It also has a delegate that runs in a synchronous mode (e.g. it's asked questions it has to answer by returning a value, instead of just being notified of events or using a callback-based response), and that's the same problem as synchronous APIs (because now the remote process has to block waiting on a response from UIWebView). WebKit2 is an existing effort by Apple to do out-of-process rendering. Various desktop apps already use it, including Safari, Mail, and iBooks. It features new APIs for doing everything, because it's all asynchronous. If third-party iOS apps gain out-of-process rendering it will be through WebKit2 and not some attempt to port UIWebView to the remote view controller system. Incidentally, the same synchronous issues with UIWebView that I mentioned above suggest that porting to WebKit2 is a non-backwards-compatible change. If Apple makes this change, I would guess that either they'll introduce a separate UIWebView class that's used for WebKit2 and leave the existing UIWebView alone, or they'll give UIWebView two modes, a WebKit mode and a WebKit2 mode, and whichever mode it uses will be selected at initialization time (and using a WebKit method on a WebKit2 UIWebView would be an error, and vice versa). Either way, apps will have to be rewritten to take advantage of WebKit2.