61

I'm not sure this is a suitable question for here but is the new Chrome app for IOS just a UIWebView?

If so then would it be safe to assume that there shouldn't be any rendering differences between it and mobile Safari?

SpaceBeers
  • 13,617
  • 6
  • 47
  • 61
  • Something to add, Chrome on iOS did not suffer from the popular 0 day SSL goto fail; flaw that was patched in iOS 7.0.6 – Isaiah Turner May 21 '14 at 04:58
  • Did it not? That's interesting. The accepted answer is 2 years old so things may have moved on since then. – SpaceBeers May 21 '14 at 08:05
  • Interesting to read @igrigorik 's [answer again](http://stackoverflow.com/a/11316946/1028230) -- It looks like UIWebView is used for *rendering*, but that's about it. ? So you could have a "network layer" that uses different code. So Chrome wouldn't be "just UIWebView", even if its rendering is. And, like Opera, it could do whatever it wanted to the html source pre-render. – ruffin Sep 04 '14 at 18:04

3 Answers3

42

No, it is not just a UiWebView. Mike Pinkerton's post on chrome-team googlegroup:

Chrome for iOS has some pretty major technical restrictions imposed by the App Store, such as the requirement to use the built-in UIWebView for rendering, no V8, and a single-process model. As a result it’s been challenging to re-use critical Chromium infrastructure components. That said, there is a lot of code we do leverage, such as the network layer, the sync and bookmarks infrastructure, omnibox, metrics and crash reporting, and a growing portion of content.

The networking layer alone contains a lot of optimizations to enhance your browsing. Here's a quick overview: http://www.igvita.com/2012/06/04/chrome-networking-dns-prefetch-and-tcp-preconnect/

igrigorik
  • 9,433
  • 2
  • 29
  • 30
28

As of version 48, Chrome for iOS uses WKWebView, which is the same view used in Safari.

Sources:

Ky -
  • 30,724
  • 51
  • 192
  • 308
  • 1
    "iOS uses WKWebView" was still true as of version 73 and subsequently 81, implied by [Debugging Websites in Chrome for iOS](https://blog.chromium.org/2019/03/debugging-websites-in-chrome-for-ios.html) and [Rethinking Payment Request for iOS Chrome](https://blog.chromium.org/2020/01/rethinking-payment-request-for-ios.html). – Schweinepriester May 10 '21 at 08:43
26

Yes, you're right... it uses the webkit rendering engine, with Chrome UI.

Ref. DaringFireball...

It’s not the Chrome rendering or JavaScript engines — the App Store rules forbid that. It’s the iOS system version of WebKit wrapped in Google’s own browser UI

Ashley Mills
  • 50,474
  • 16
  • 129
  • 160
  • I thought as much. I've not had much app development experience but I didn't think there was another way of loading a webview. I think I'm struggling to see any advantage to it over mobile Safari. – SpaceBeers Jun 29 '12 at 09:30
  • And, it would seem, that's how Apple wants it. The UIWebView is severely limited unfortunately. On OSX, the WebView and Objective-C Webkit bridge are absolutely amazing. iOS, almost all that bridged functionality is missing. – Dave Martorana Jun 29 '12 at 16:30
  • 1
    It seems like an odd thing to release to be honest. Hence the question. The only thing I can think is that it's a way of showing how closed IOS is. – SpaceBeers Jul 02 '12 at 10:54
  • 1
    Same rendering engine, but perhaps Chrome's UI may be better, faster (at least in top level browser UI portion)? – David Jul 03 '12 at 06:39
  • 2
    Advantage: syncing profile data with one's Google account. – Spain Train Jul 24 '17 at 22:45