Category:

When iOS 7 launched, developers discovered that their apps with built-in web browsers were unable to achieve the same level of JavaScript performance as the stock Safari app. This was because Apple restricted use of its improved Nitro JavaScript engine to its own app, leaving third-parties with a slower version.

A few teasers: API is the same across iOS and OS X, and the new WKWebView on iOS is running JS just as quickly as Safari.

As of iOS 8, however, it seems that decision has been reversed. All apps will now be able to use the same improved JavaScript engine that powers Safari. That means Google’s Chrome browser on iOS will now be just as quick as Safari, as will the pop-up browsers embedded in apps like Twitter and Facebook.

29 Responses to “iOS 8 WebKit changes finally allow all apps to have the same performance as Safari”

Apple would have to change their stance over allowing web rendering engines. Right now all browsers on iOS are basically Safari with different UI. Some browsers like SkyFire will render on the server, but anything that renders on the device is using the WebView and is powered by Safari. Mozilla refuses to have Firefox run on iOS unless they can program their own layout engine and JavaScript engine. So no Firefox on iOS for now.

I’d put it the other way around: Apple refuses to allow any browser on iOS that doesn’t use their layout & JS engine. Even Google’s Chrome on iOS is just a different wrapper for the same Safari guts. I guess Mozilla could do something similar, but what’s the point?

The point is simple – to have a browser with UI similar to the one used on desktop and that syncs data with it (bookmarks, passwords, open bookmarks, etc.). And possibly is faster with adding new features than Apple (they basically doing that one time in a year, while other browsers get new features every few months).

Annoys the hell out of me. Microsoft in 2001 were smacked with a massive antitrust lawsuit when bundling IE with Windows and throttling Netscape’s growth, but Apple can restrict companies from building their own browsers with bespoke rendering engines. Stupid.

Totally wrong there is a “ToS” stopping a company from building their own browser engine. MS didnt get away with it in the beginning of the millennium, so i dont understand why Apple is getting away with it now.

Chrome on iOS just used UIWebView (old Safari runtime), which is slower than iOS7/8 Safari app which uses WKWebView, with iOS8 SDK people can use WKWebView so people can create web based rendering as fast as Safari. I dont think apple allows you to create a browser with your own runtime, u have to use UIWebView or WKWebView

I wonder how this can be true when all the other App Store TOS are still in place. Like effective RAM limitation and alike. Native Safari seems to be nearly unlimited in ressource use which for obvious reasons won’t apply to any 3rd party apps…

“I wonder how this can be true when all the other App Store TOS are still in place.”

The WKWebView component runs in a separate process with special permissions. That way, the app technically doesn’t have to violate the ToS and, assuming the interprocess communication mechanism is solid, security is maintained.

You have to use WKWebView instead of UIWebView to get performance like Safari, WKWebView is 2x-10x faster, I have created an app that can be opened using either UIWebView or WKWebView to check performance: http://www.initlabs.com/projects/webview-app

This language suggests that the original Apple decision was based on malice. This is not the case. The original decision was based on security concerns because the high speed JVM generates new code that has not been vetted by Apple and which runs in an unknown environment (ie another browser).

I’m guessing that this change has been made because either it’s been validated that, no matter how awful the JS, the JIT can’t generate dangerous code OR (more likely) the JIT has been moved to generate code that runs in a separate process, with XPC providing a controlled connection between the address space the JS is running in and the browser itself. This second model matches what Apple has been doing on both OSX and iOS for the past few years — segregating possibly dangerous code into its own jail, with the only communication channel available to it being tightly controlled XPC.

Safari “Reader Mode” is a killer must have MOBILE feature. Even on big Android phone Chrome ,without reader mode, is not a great experience. Google will never build a reader mode because it strips out their main revenue….Ads. Same Webkits won’t sway me away from Reader mode.