3 ms·

How have they made it so anyone using their engine is a 2nd class citizen? Does the engine perform differently outside Safari?

kibwen 12y ago
Last I checked, iOS's third-party app policies forbid the implementation of anything akin to a JIT compiler, and even third-party usage of the standard WebView component disables the Nitro JIT. I'm not an iOS dev though, I have no idea if there's been any progress in this space recently.
- piyush_soni 12y ago
  Yeah, it's seemingly changed since you last checked. Now they allow you to use the Nitroj JIT. I'm not an iOS developer as well, just heard it.
- ziahamza 12y ago
  Its changed now with IOS 8, JIT is enabled for WKWebkit
  - giovannibajo1 12y ago
    To be precise, it's not that JIT is now allowed in iOS; that would be a security issue because it would basically allow sandboxed apps to create executable memory area, which is considered very bad. On the contrary, what just happens is that WKWebView is piggy-backing on the new extension system to run in a different process, with a different relaxed sandbox, and communicates to the host app with an IPC channel (similar to eg. Chrome extensions). It looks like there are not enough features exposed over this IPC channel to make a fully featured browser, yet.
daxelrod 12y ago
Essentially, yes. To elaborate on the linked bug a bit: You can use UIWebView, the older interface. The biggest problem is that its JavaScript engine is slower than Safari's, and does not JIT compile code (according to Apple, this is for security reasons). I've also seen complaints about scrolling performance. You can use WKWebView, the newer interface. Its JavaScript engine does JIT, and it boasts 60fps scrolling. Unfortunately, it's missing several features detailed in the bug, including a way to clear and manage cookies, custom URL handlers, POST request bodies missing in certain cases, etc. One would hope that the WkWebView bugs and omissions will be addressed in future iOS versions, but today is not possible to make an iOS browser that works as well as Safari.

kibwen 12y ago

Last I checked, iOS's third-party app policies forbid the implementation of anything akin to a JIT compiler, and even third-party usage of the standard WebView component disables the Nitro JIT. I'm not an iOS dev though, I have no idea if there's been any progress in this space recently.

piyush_soni 12y ago
Yeah, it's seemingly changed since you last checked. Now they allow you to use the Nitroj JIT. I'm not an iOS developer as well, just heard it.
ziahamza 12y ago
Its changed now with IOS 8, JIT is enabled for WKWebkit
- giovannibajo1 12y ago
  To be precise, it's not that JIT is now allowed in iOS; that would be a security issue because it would basically allow sandboxed apps to create executable memory area, which is considered very bad. On the contrary, what just happens is that WKWebView is piggy-backing on the new extension system to run in a different process, with a different relaxed sandbox, and communicates to the host app with an IPC channel (similar to eg. Chrome extensions). It looks like there are not enough features exposed over this IPC channel to make a fully featured browser, yet.

daxelrod 12y ago

Essentially, yes. To elaborate on the linked bug a bit: You can use UIWebView, the older interface. The biggest problem is that its JavaScript engine is slower than Safari's, and does not JIT compile code (according to Apple, this is for security reasons). I've also seen complaints about scrolling performance. You can use WKWebView, the newer interface. Its JavaScript engine does JIT, and it boasts 60fps scrolling. Unfortunately, it's missing several features detailed in the bug, including a way to clear and manage cookies, custom URL handlers, POST request bodies missing in certain cases, etc. One would hope that the WkWebView bugs and omissions will be addressed in future iOS versions, but today is not possible to make an iOS browser that works as well as Safari.