Skip to main content

iOS 8 WebKit changes finally allow all apps to have the same performance as Safari

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.

[tweet https://twitter.com/vickimurley/status/473955064629829632 align=’center’]

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.

FTC: We use income earning auto affiliate links. More.

You’re reading 9to5Mac — experts who break news about Apple and its surrounding ecosystem, day after day. Be sure to check out our homepage for all the latest news, and follow 9to5Mac on Twitter, Facebook, and LinkedIn to stay in the loop. Don’t know where to start? Check out our exclusive stories, reviews, how-tos, and subscribe to our YouTube channel

Comments

  1. Joshua Clark - 10 years ago

    so does this mean firefox will come to ios now?

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

      • Joshua Clark - 10 years ago

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

      • Les Orchard - 10 years ago

        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?

      • revanmj - 10 years ago

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

      • Rbels Km - 9 years ago

        Not the case.. noticed few java script works differently on safari and chrome.

      • garfbradaz - 9 years ago

        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.

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

  3. andrewtheis - 10 years ago

    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.

    • jakexb - 10 years ago

      Not true, it uses ios webview with its own UI. It’s against the TOS to do your own browser engine.

      • garfbradaz - 10 years ago

        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.

    • IDK where you got this info… But it’s false.

    • kplayaja - 10 years ago

      Wrong. Chrome was just a slower Safari with Chrome skin.

    • Rakshith (@krisrak) - 9 years ago

      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

  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.

  5. decoratiff (@decoratiff) - 10 years ago

    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…

    • degraevesofie - 10 years ago

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

  6. Eric Haight (@erichaight) - 10 years ago

    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.

  7. Gerrit van Aaken - 10 years ago

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

  8. name99 - 10 years ago

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

  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.

    • ianbarlow - 10 years ago

      You should try Firefox for Android — has a great Reader Mode feature. Even nicer looking than Safari’s IMO :)

  10. Stetson - 10 years ago

    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.