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.
#Do i iphone use safari or google chrome 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)
