Historically, the code for Chrome for iOS was kept separate from the rest of the Chromium project due to the additional complexity required for the platform. After years of careful refactoring, all of this code is rejoining Chromium and being moved into the open-source repository.
Due to constraints of the iOS platform, all browsers must be built on top of the WebKit rendering engine. For Chromium, this means supporting both WebKit as well as Blink, Chrome’s rendering engine for other platforms. That created some extra complexities which we wanted to avoid placing in the Chromium code base.
There is no Chrome for iOS. It doesn’t exist. Just because it has a Chrome-like UI doesn’t mean it’s Chrome. Chrome is the whole package – UI and engine. Without the engine, it’s not Chrome. I understand Google wants to leverage the brand recognition, and I know I’m splitting hairs, but until Apple allows competing browser engines, iOS only has one browser, with a bunch of skins.
Here’s why chrome for iOS is not irrelevant – shared history. I totally forgot about chrome for iOS, this article just prompted me. You know why I just installed it? Because one of the things that irks me about iOS is that Safari bookmarks, etc, are only on my phone – everything else is in chrome on my Mac/PC/Android devices. Just installed it – wow, I have access to not only my bookmarks, cross device, but my recent tabs on other devices. There’s your USP. That is why I’ll now use chrome along side Safari.
Same reason why people have Firefox on iOS I believe.
One of the reasons people might choose Firefox over Chrome is because Mozilla encrypts your data and stores it encrypted. Mozilla has no access to the data, so they can’t monetize it. Google on the other hand… is different.
Edited 2017-02-01 11:07 UTC
iOS is built according to the game console mentality: Only code that has been signed (aka approved) by the manufacturer can run, and devs must use the frameworks provided by the OS like WebKit (much like Xbox games had to use the Xbox Soundtrack music collection to play custom in-game music and couldn’t just store music in their own format in the harddrive).
That’s the product, no reason to whine about it when there are other choices.
Edited 2017-02-01 09:55 UTC
no reason to whine my ass. Didn’t we all whine when was internet explorer?
Web “standards” in those days consisted of a little button link saying whether the designer wrote the page for Internet Explorer or Netscape. A lot of websites required ActiveX for no justifiable reason; just because that’s what the developers knew (or to sneak in some malware).
The fact that Apple’s WebKit implementation is the only choice on the most economically significant mobile platform, and Google’s is the most popular on nearly all other platforms (most of which have no access to Apple’s) has the interesting side effect of forcing websites to write to standards instead of browsers. If sites could tell iOS users to just go download Chrome and set it as their default browser, we’d probably still be using Flash.
So the experience of not having full control of your computing device and being under the corporate master’s thumb are analogous, but the network effects that made IE “evil” do not apply. They’re practically reversed.
It is a clarification for people that don’t know. If these details don’t get mentioned people might not know.
And it’s an important detail.
You’re mistaking mechanism for motivation. Game console manufacturers require code signing primarily to collect revenues. Apple isn’t collecting revenues from free copies of Chrome.
Apple’s use of code signing, and WebKit, has to do with security, quality, performance, and consistency of user experience. Have you ever tried to do a security audit of the entire Blink rendering engine? Now, multiply that times the number of releases that Chrome turns over to Apple for inclusion in the iOS app store.
If Apple finds a security vulnerability, rendering flaw, or if they come out with a performance improvement in WebKit, updating it fixes all of the browsers on iOS, not just Safari.
No, Apple doesn’t allow custom code parsers on iOS because it would jeopardise their App Store-only model. Whatever user experience aspects you’re talking about, they’re just side effects.
This is exactly right, and frankly it’s a better model for 90% of end users who are simply never going to learn enough about the tech to keep themselves safe.
What they need to add is some kind of store front capability. Some way for other store fronts (imagine a Steam or Nintendo storefront) to tap in, and deliver a curated app shopping experience, and share some of the revenue for that effort. That would go a long way to clean up horrible mess that is the App Store.
Edit: None of this is to say I think Apple makes 100% correct decisions – I dislike that I can’t set Signal as the default SMS app on iOS for example, and there are many other aspects of Android that I prefer (though Google’s snooping isn’t one of them).
Edited 2017-02-01 17:07 UTC
True, however the sword can sometimes swing the other direction. If Apple messes up Webkit, they break all browsers and not just Safari. Just because it hasn’t happened yet doesn’t mean it couldn’t, and we all know that Apple aren’t infallible (iOS 8.0.1).
I wouldn’t want to actually use Chrome on iOS, as it’s a non-native UX and an exercise in handing Google more personal data. But even without trusting Google to store my main browser data, the fact that they’re an advertising company comes in handy occasionally.
Safari blocks cross-domain cookie access as a sane browser should, but since that’s how you stalk users to show them ads for what they’ve been looking at lately, Chrome does not.
Enter video apps that rely on a cable subscription: they launch their channel’s website, which opens a frame view into a cable provider’s website. Instead of having the latter return an oauth token in an HTTP request or sharing any information server-side, they just share a cookie. So that’s a legitimate(ly bad programming) reason to keep a browser around that doesn’t value personal privacy.
(There’s a perfectly good chance that was a setting I changed on the Safari side, but I don’t intend to ever change it back, so keeping an extra app around for the edge case suits me just fine.)