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.
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.
Aw that sucks! :( I want Firefox on my iphone! and make it my default :(
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).
Not the case.. noticed few java script works differently on safari and chrome.
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.
i wish we could select an app by default (messaging, browser, camera….) that’s the only thing iOS 8 is missing!
Good point! This would be very helpful for a lot of people.
Completely forgot about that… I suppose the extension part can serve as that. It’s one step away but at least you don’t have to copy and paste.
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.
Not true, it uses ios webview with its own UI. It’s against the TOS to do your own browser engine.
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.
Wrong. Chrome was just a slower Safari with Chrome skin.
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
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.
I guess that’s why this happens any time I try to load a website
https://15104268797498972201.googlegroups.com/attach/81cc00a754fc36de/10380309_703136863079980_3329286721175544445_n%5B1%5D.jpg?part=0.1&view=1&vt=ANaJVrEaJX2iUBHHoBH_pOaMgWU1u8M1NgbRlD8mzSFDM-R3JxjPhibxdZT_i3PObPgPZVSljBmHa-Lci2MLTG1IQZLpuoZkIX9bAyC-Xh3_AU6t9uDFpi4
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.
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.
Sounds like you’ll have to migrate your app from UIWebView to WKWebView to get the performance increase.
In Apple’s own words in “Introducing the Modern WebKit API” (https://developer.apple.com/videos/wwdc/2014/): “increased JavaScript performance via WebKit’s super-fast JIT”.
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
Is this also true for “homescreened” web apps? They too still suffer from decreased JS performance in iOS 7.
“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.
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.
You should try Firefox for Android — has a great Reader Mode feature. Even nicer looking than Safari’s IMO :)
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.