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.

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.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

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

  1. Joshua Clark says:

    so does this mean firefox will come to ios now?

    Like

    • 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.

      Like

      • Joshua Clark says:

        Aw that sucks! :( I want Firefox on my iphone! and make it my default :(

        Like

      • Les Orchard says:

        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?

        Like

      • revanmj says:

        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).

        Liked by 1 person

  2. i wish we could select an app by default (messaging, browser, camera….) that’s the only thing iOS 8 is missing!

    Liked by 1 person

  3. andrewtheis says:

    Google Chrome was already fast or as fast as Safari. It didn’t use the UIWebView API, but it’s own bundled version of WebKit.

    Like

  4. Apple has explicitly mentioned that the reason UIWebKit was slower than Safari was a security related technical issue, not a strategic decision.

    Even with UIWebKit being slower than Safari though, I always found that UIWebKit was faster than Android Chrome in real world experiences.

    Like

  5. 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…

    Like

    • degraevesofie says:

      “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.

      Like

  6. Hmm this article does not seem to be correct, I wish it was, but it does not look like performance in App WebView is the same as Safari in iOS8. Performance still seems to be limited in WebView.

    Can you confirm source that performance should / will be the same in iOS8 Webview and Safari? Our tests do not agree with what is stated here in the latest iOS8.

    Like

  7. Is this also true for “homescreened” web apps? They too still suffer from decreased JS performance in iOS 7.

    Like

  8. name99 says:

    “As of iOS 8, however, it seems that decision has been reversed.”

    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.

    Like

  9. 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.

    Like

  10. Stetson says:

    Some background information:

    http://daringfireball.net/linked/2014/06/09/ios-8-webkit

    In summary, this has been the case since iOS 4.3, not iOS 7. It isn’t really a “reversed decision”, rather an improvement in software that allows it to now be done securely.

    Like