No, it just means that instead of Chrome for Android and Chrome for iOS having different versions of WebKit, Chrome for Android will use Blink and Chrome for iOS will use the system WebKit, as it does now.

So Google will be using 2 increasingly different rendering engines for Chrome in the future? Well that sucks. Apple really needs to allow other rendering engines on iOS, or at least be forced into it. People complain about the "webkit mono-culture", but a huge platform like iOS actually mandating you use webkit, and their single version of webkit, is a lot worse.

They already are different: Chrome on iOS uses whatever version of WebKit UIWebView uses on the platform (which, until relatively recently, was an old fork of WebKit), whereas Chrome on Android nowadays uses a version almost as up to date as Chrome on desktop.

We're a bit worried about compatibility, certainly. One important thing to note is that WebKit has _tens of thousands_ of layout tests; all of those tests exist right now in the Blink repository, and we're certainly going to continue working with browser vendors in general and the W3C to ensure that we can agree on exactly what standards mean, and how they should be rendered.

We'll be coming at the same problems from different angles, find and fix different bugs, and have the opportunity to peek at how other browsers have done things. I'm quite hopeful that will mean that we'll all end up with better implementations.

I agree, that would suck. Specially if -for some reason- we start seeing differences in terms of rendering speed/js engine/or other techs between the android version and the iOS version.

There already are speed differences in iOS alone. The native Safari has a faster JavaScript engine than the sandboxed Safari instances that iOS apps use.

Or something like that. Something about security concerns.

It's the JIT for JavaScript that's disabled. I've never seen an official statement on it but I've read that it's that the security model in iOS does not allow compiling code and then executing it, but Mobile Safari gets a unique bypass for this security. Other apps which merely embed a UIWebView are stuck with interpreted JavaScript.

unless you have nitrous installed. http://lifehacker.com/5930405/nitrous-speeds-up-google-chrom...

Any user process cannot allocate executable memory, hence you cannot have any JIT.

The Android and iOS versions have always been different. Apple does not approve any browser apps that do not use the default UIWebView.

It was this reason that Adobe could never launch a flash enabled browser on iOS.

This is already true today.

Well, then it's already sucky :) I never tried/used the android version.

They allowed Opera on the market. They allow other engines. They just don't allow private source code. Which just so happens to be part of Chromium.

Opera on iOS is actually Opera Mini, which doesn't run a rendering engine on the device at all.

And no, Apple does not allow other rendering engines so much. Specifically, they do not allow anything that can execute code that is not distributed with the app. So for example, no JS engine that's allowed to run scripts that don't ship with the app, period (even without a JIT).

Nope, no changes for Chrome for iOS: current version already uses UIWebView and will continue to do so. The rest of the infrastructure (networking, etc), is Chrome code.

Chrome for iOS is just a wrapper around Safari.

Chrome for iOS uses a UIWebView for rendering (effectively Safari), but uses the Chromium networking layer, UI (omnibox), etc. Arguably though rendering/JS is a big part of what makes the browser the browser, but it isn't everything.

Not at all. iOS version uses UIWebView, but all the rest is Chrome code.

UIWebView means DOM, CSS and JavaScript is brought by mobile safari? All the stuff to show and run a web page?

Yes. Apple doesn't let you do the parts that make a browser tick.

They will probably keep WebKit for the iOS version.

They have no choice in the matter, unless Apple starts allowing other engines on their phones.