There is at least one missing feature, though. One WebGL test ran twice as fast in WKWebView, and another used 25 percent of the CPU to render particles at 60fps where UIWebView uses 90 percent of the CPU to accomplish the same task. An iOS 8-era comparison of UIWebView and WKWebView demonstrates these improvements. Google promises improvements in scrolling and responsiveness as well, and WKWebView brings with it better HTML5 compliance and faster WebGL performance for browser-based 3D applications. Not everything is going to get ten times faster, but the speed improvement should be readily visible. JavaScript performance gets a huge boost, best shown off in a heavier benchmark like Google Octane. The most visible benefit of WKWebView in Chrome is going to be its speed. Mardini said that Google worked with Apple extensively between the release of iOS 8 in September of 2014 and the release of the first iOS 9 beta in June of 2015. “Apple did fix or provide some APIs in iOS 9 that made us consider the migration." Not just about speed (but the speed is nice, too)
“There were things related to cookie management, there were things related to security and our view of the Apple security stack, which would have made us lose certain functionality related to knowing more about the SSL certificate,” AbdelKarim Mardini, a Chrome Product Manager at Google, told Ars. Luckily, many of these problems were fixed in iOS 9. The Chrome team’s biggest problems with the API are laid out in this page on the Chromium issue tracker, but it’s clear that the original version of the API was made with apps like Facebook in mind, apps where people visit pages but don’t serve as anyone’s primary browser. WKWebView was a huge improvement over UIWebView in a lot of ways, but there were some missing features for browser developers. Advertisementįast-forward to iOS 8, and Apple finally made Nitro available to developers via a new API called WKWebView. They could offer their users familiar UIs and cross-platform syncing, but from iOS 4.3 to iOS 7.1, third-party browser makers (and any app developers that used UIWebView to render pages within their apps instead of bouncing users out to Safari) had to settle with second-rate JavaScript performance on iOS among other problems. The upshot was that third-party browser makers could neither use their own browsing engines nor use the best possible version of Apple’s engine. The company cited security concerns at the time. Formerly known as SquirrelFish Extreme, this engine dramatically improved Safari’s JavaScript performance, but the catch was that Apple didn’t make Nitro available to third parties via UIWebView. Way back in iOS 4.3, Apple started using a new version of the Webkit JavaScript engine called Nitro. The oldest API for this in iOS is called UIWebView. Developers can build browsers, but they’re always just wrappers for the platform’s Webkit-based first-party engine. On iOS, Apple has never allowed third-party browsing engines. Safari uses WebKit, Microsoft Edge uses EdgeHTML, Chrome uses Blink, and Firefox uses Gecko.
#IOS WEBKIT ANDROID#
On Android and the major desktop platforms, different browsers use different rendering engines.
Further Reading Chrome for iOS review: syncing is great, but still just an iOS WebKit wrapper
0 kommentar(er)
