Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Google Chrome now works on iOS (techcrunch.com)
198 points by jpadilla_ on June 28, 2012 | hide | past | favorite | 118 comments


But, Chrome on iOS will still be a "second class citizen" the way Opera mini and the other browsers on the AppStore. If you want to open a link in Chrome, you will need to copy/paste the URL, no "Open in Chrome" functionality like Safari has. For better or for worse, Apple has not opened up system-wide integration of third party apps, and I don't seem them allowing you to change your default browser anytime soon.


What's pretty nauseating about it is that it's exactly the kind of anti-competitive crap that Microsoft pulled in the first browser war, only more so.


Why do people keep bringing this up? The situations are completely different.

Microsoft bundled IE with Windows at a time where the internet was still painfully slow and it was difficult to download a different browser. They also allegedly put IE-specific APIs into Windows, giving it an unfair advantage.

However, neither of these would have been enough to convict, if Microsoft hadn't also had a monopoly over the PC. Back in those days, Windows was _the_ operating system. Linux was still new and unknown, and Macintosh wasn't a threat by any means. Bill Gates was sometimes compared to the president in terms of power and influence.

Bundling Windows and IE was an abuse of Microsoft's monopoly in the OS market, in a successful attempt to take over the browser market.

Apple has no such monopoly. Like many others have said here before, if you don't like what they do with their platform you can choose not to buy apple products. When you say they're being anti-competitive, you're implying that iOS and OSX are massive ecosystems which include meaningful competition in sub-markets that Apple is giving itself an unfair advantage in. No such sub-market exists.


> Like many others have said here before, if you don't like what they do with their platform you can choose not to buy apple products.

And also like many others have said before, that's not a difference. You could choose not to buy Microsoft products in the '90s. I did it. The place I worked did it. Most people and places simply didn't make that choice because Microsoft seemed like a safer purchase.

Also, Apple has pretty much the same position in the tablet market that Microsoft did in the PC market. I can't remember the last time I saw someone holding a non-Apple tablet who wasn't trying to sell me one.


>Also, Apple has pretty much the same position in the tablet market that Microsoft did in the PC market. I can't remember the last time I saw someone holding a non-Apple tablet who wasn't trying to sell me one.

Rather than blindly speculating, we can look at actual facts.

Today Microsoft has 93% of the desktop OS market.[1] Considering the recent rise in popularity of both OS X and Linux I would guess that was higher in the 90s, but I have not done enough research to be sure

Apple's iOS today has 63% of the mobile market.[2] While that is still the majority it is not close to Microsoft's desktop dominance even today.

So maybe you only socialize with Apple fans but your circle does not represent the market as a whole.

[1] http://marketshare.hitslink.com/operating-system-market-shar...

[2] http://marketshare.hitslink.com/operating-system-market-shar...


You're saying that if (when) Microsoft will fall to some percentage (63%, for example) in desktop market, they can appeal anti-monopoly regulations and force IE within Windows again?


Yeah, but that's the mobile market. That includes phones as well as tablets. Android has clearly made great inroads in the phone market: I think it actually has a market share of over 50% in phones (well, smartphones, anyhow). Unfortunately, the same cannot be said for tablets; for whatever reason, Apple still maintains a very strong position in the tablet market.

I'm too young to know for sure, but I bet Microsoft only ever had a monopoly in the desktop market and never in servers or the like.


Mobile market != tablet market


Well, how about putting in MobileSafari-specific APIs into iOS for marking memory write+executable, a necessity for performant JIT? :)


I keep reading, there is no tablet market except for ipad. Why is that not considered monopoly?


Let me preface this with IANAL, just a very interested person.

It may very well be, but having a monopoly alone isn't not a crime. A crime in this case would be abusive practices of the monopoly.

What makes United States v. Microsoft different is a number of factors but the main factor was its restrictive licensing agreements with other OEMs. You could buy a computer from a variety of makers, but no matter what, this IE/Microsoft abusive relationship allegedly existed.

What this means is if you were an OEM, not only did you carry Windows as the operating system but that agreement forced you, the OEM, to package and include Internet Explorer. As others have pointed out at this time, downloading and installing alternative web-browsers was also a slow proposition or required someone visiting a store.

In particular it was ruled that Microsoft violated Sections 1 and 2 of the Sherman Antitrust Act

Apple does not have a monopoly over the dominant operating system for all tablets, only its own. Yes right now it is the dominant product in the space, but alternatives readily exist with the same availability as the iPad. You may argue that the Samsung case is an abuse of monopoly, I don't believe it is, abuse of IP law, perhaps - but that's a different discussion.

The way the situation would be analogous is if the majority of all tablet makers, all used iOS, and were forced by Apple to configure their installations in a way that benefited Apple products while hampering others. And even then it might not be the same, depending on how courts view the iPad as a device.


> It may very well be, but having a monopoly alone isn't not a crime. A crime in this case would be abusive practices of the monopoly.

Like not allowing third-party browsers to compete with your own on anything remotely resembling a level playing field? That's what we were talking about here, remember? Apple won't allow alternative browser engines at all, and if you decide to build a browser using the engine Apple provides for third-party devs, it's worse than the one Apple uses in its own browser.

> Apple does not have a monopoly over the dominant operating system for all tablets, only its own. Yes right now it is the dominant product in the space, but alternatives readily exist with the same availability as the iPad.

Macs were not particularly less available than PCs in the '90s. I didn't know anyone who really wanted to buy a Mac, but just couldn't find one. They were just radically less popular and generally considered to be a bad choice (I liked them even then, but I didn't have a lot of company with that opinion). Much like non-iPad tablets.


Again though, Apple is one manufacturer. They make a device and supporting software for that device. Unlike the situation with Microsoft where they were licensing software to multiple device makers. It was the OEM agreements that led to them running afoul of antitrust.

Since Apple sells a hardware device with software they are entitled to do whatever they want with it. This is true of Android of course too, as we know device manufacturers often modify Android to suit their needs or the needs of their networks, why else do people speak of having to root their devices?

That's what makes it an non-abusive monopoly, they aren't dictating the rules for the vast majority of device makers, and doing so in a way to benefit their products unfairly.


More so. But Apple tends to get good grades on the perception front, which is no less important for the general public than the technical front.


And while Mozilla made really loud noises with threats of complaints and legal action about Windows RT and Microsoft, they completely ignored Apple and made Firefox Sync which just syncs bookmarks etc.


"they completely ignored Apple and made Firefox Sync which just syncs bookmarks etc."

There was plenty of sounds from them at the time when they wanted to release a Firefox for iOS, but that was a few years ago by now and it didn't get picked up in the media like the Windows-complaints.


>There was plenty of sounds from them at the time when they wanted to release a Firefox for iOS

Really? Care to link to some of them?


Here's one that I was personally involved in:

http://www.zdnet.com/blog/hardware/will-firefox-mobile-ever-...

Honestly, we are just as upset about Apple's restrictions on iOS, but we the Windows 8 case may prove different because of Microsoft past agreements with the US DOJ. If the courts decide that agreement should apply to Windows desktop on ARM then that provides very different leverage than anyone has against Apple.


You're comparing a reply made to a Quora question by a Mozilla developer(sounds more like personal opinion) to a blog post about Windows RT on Mozilla's official site penned by their General Counsel? I don't see how they're remotely comparable.


Note: I am that Mozilla developer, which is why I remembered that press coverage in particular. For a less personal example, see comments to the press in 2009 by John Lilly (then CEO of Mozilla Corporation):

"Given the choice, would we work on a platform where the sole company controlling it makes us unwelcome, or would we work on a platform, like Linux, where we are welcome? The answer is going to be easy for us." ... The danger of a gatekeeper like Apple on the iPhone is that innovation is stifled, Lilly argued. "These vertical silos don't enable innovation," he said. [1]

Our general counsel gets involved where there is a legal case to be made or legal questions to be answered. There's no current legal case against Apple; I'm not a lawyer so I have no idea if a legal complaint would make sense. But in the meantime, we have no real ability to change Apple's actions.

I think we would complain more loudly or frequently in the press if we thought it would get picked up and have some positive outcome. My personal experience is that, after four years with no change in the situation, people either agree with us already or they think we're just whining. And Apple itself has never really cared when third parties complain about this policy. I'll add that there's not total agreement within Mozilla about this. Some people think we should stay aggressive in these political battles regardless of outcome; others think it's better not to "go negative" and that we should focus more energy and attention on the platforms where we are able to carry out our mission.

[1]: http://www.computerworld.com/s/article/9128119/Mozilla_backs...

(That story was mainly about Mozilla/EFF testimony in 2009 in favor of the DMCA jailbreaking exemption, which Apple lobbied against. These exemptions must be renewed every 3 years, so Mozilla mobile developer Brad Lassey just presented at the Library of Congress last month in favor of renewal -- but the press did not even report on this year's hearings, which perhaps shows how people lose interest once something is "old news.")


I'm not one to be late on admitting I was wrong, and it seems I was here. After having searched for some, I realize that I must have mixed up criticism from Android-people with official Mozilla statements over the years. This is the closest I found:

http://www.quora.com/Will-Firefox-Mobile-ever-be-released-fo...

It's possible some of the blog entries/twitter posts I seem to remember have been lost over time, though. Excuse me, and feel free to downvote my original post. I should have done some searching myself before posting it.

EDIT: This is somewhat related, but more about pushing B2G as alternative than to improve the situation on iOS: http://www.techradar.com/news/computing/apple/mozilla-fires-...


https://www.computerworld.com/s/article/9188721/Mozilla_Forg...

http://blog.mozilla.org/mobile/2010/09/28/firefox-home-looki...

I have not heard them use the monopoly complaints against Apple. I'm sure Mozilla is worried about Apple, but is using a different strategy since an argument that Apple is abusing monopoly is weak or underdeveloped.

Mozilla might believe that Apple is a better actor in the open web space than Microsoft.


From the Mozilla blog post you linked:

>We are working to bring as much of your Firefox experience as possible to Firefox Home. People have asked about adding more browser-like features to Firefox Home, but there are technical and logistical restrictions that make it difficult, if not impossible, to build the full Firefox browser for the iPhone. We are focused on building Firefox Home as a rich, cloud-based application and making it a valuable product that people will continue to love and use.

Compare it to the tenor of this post:

http://blog.mozilla.org/blog/2012/05/09/windows-on-arm-users...

See the difference? Mozilla didn't even make a call for browser choice officially on the iPad before resigning itself to making just Firefox Home and Sync. Also, if you notice, Mozilla hasn't mentioned Apple or the iPad/iPhone even once in their long blog post. My guess is that is because it undermines the point they're trying to make.

>I'm sure Mozilla is worried about Apple, but is using a different strategy since an argument that Apple is abusing monopoly is weak or underdeveloped.

Yet, we keep hearing things like "There is no tablet market, there is only an iPad market" and then Mozilla tries to go after the platform that has 0% share leaving the 800lb gorilla alone, maybe because that generates the most PR?


I agree that Mozilla could be choosing to battle Microsoft here instead of Apple battle for the positive reputation and press.

Mozilla could be wary of a long-term Microsoft gambit. When does Windows and Windows RT just become Windows?

Apple gets to do things that Microsoft as a proven monopoly and past abuser of that monopoly. I'm as worried about the future Apple as I'm about the current Microsoft. As long as Apple continues to clearly differentiate its more open software ecosystem MacOS from its less open software ecosystem iOS, perhaps it's not as much of a worry?


or maybe that's the impression you have because it generated the most PR?


What a bunch of walled-garden bullshit. It's not even clear that having a full featured Chrome would hurt Apple in anyway


They want to keep the threat of making Bing the default search engine.


>It's not even clear that having a full featured Chrome would hurt Apple in anyway

Perhaps this is how Apple sees it:

The browser might create a SDK that makes web apps work more like native apps thus resulting in reducing Apple's control over apps. Also, look at things like NaCl and how plugins like Flash might be enabled by browsers with rendering engines.


I think this is exactly how Apple sees it. Look at the specific language from the SDK agreement:

"Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework."

This doesn't forbid third-party interpreters; what it really does is control distribution of code. All code that is run on an iOS device must be downloaded either through the App Store or through Apple's WebKit.

This means there are no distribution channels on iOS that use their own non-Apple mechanisms to obtain and run software -- no Flash Player, no Chrome Web Store with NaCL, not even MIT's Scratch programming environment for kids (whose runtime was banned from the App Store in 2010 [1]). Web apps on iOS are less controlled than native apps, but Apple still gets to decide which capabilities to expose to them. This is one of the major things that gives Apple such tight control over the user experience, security, and evolution of the platform.

[1]: http://computinged.wordpress.com/2010/04/15/apple-removes-sc...


> The browser might create a SDK that makes web apps work more like native apps thus resulting in reducing Apple's control over apps.

This claim come up occasionally. It always seems silly because web apps were the ONLY apps in the original iOS. Native apps came later and only with pressure from the development community.


> It always seems silly because web apps were the ONLY apps in the original iOS. Native apps came later and only with pressure from the development community.

I think that is a silly claim, web apps were pretty useless at the time, there were almost no html5 features at the time so web apps were no threats at all while Apple was adding support for apps.


> there were almost no html5 features at the time so web apps were no threats at all while Apple was adding support for apps.

The issue with this theory is that Apple did not want to add support for native applications, only developer pressure made them (Steve Jobs, mostly) relent, and order the cleanup and release of a native SDK.


>It always seems silly because web apps were the ONLY apps in the original iOS

I don't know why it seems silly to reckon that Apple's priorities on web apps has changed now that they have their own app store and control over it. You mean Apple's opinion on web apps has to be unchanged from the original iPhone?

When was this page last updated? http://www.apple.com/webapps/

Also, even after Jobs' Flash post more than two years blasting Flash and promising HTML5 improvements to replace it, we still haven't seen much improvement in HTML5 in iOS, with things like audio still suffering. If there were no App store, Apple would've easily devoted more resources to this.


Even simpler than that, in iOS 5, Apple broke local storage (by putting it in a cache folder than gets emptied every so often), making offline HTML5 apps unworkable.

A cynical mind might think they did that specifically to keep HTML5 from getting any closer to replacing the app store.


Fragmentation lowers the quality of the product. Apple has consistently made a design choice with the iPhone to shoot for quality rather than freedom, and evidently a lot of people like that tradeoff.

Maybe it doesn't have to be a tradeoff. But until all major carriers are selling an unlocked, rooted Android phone with guaranteed long-term OS updates with build quality and software stability as good as the iPhone, I'm going to continue to defend the idea that Apple's design choices are a perfectly valid set of tradeoffs to bring to market.

Some people (myself included) love Apple products because Apple's abstractions don't leak (much). If my grandmother has to be aware of the fact that she's using a "browser" with a "rendering engine," much less understand which one or which version, Apple has no UX advantage.


That shouldn't be that much of a problem as most of the pages on iOS are displayed in an in-app web views (in apps like: Twitter, Facebook, etc.). Ok, "bookmark-icons" will open in Safari - doubt it's a very popular feature though.


Exactly what the users should be requesting from Apple. You're lucky Apple at least tries to be competitive on the browser front, but if they didn't do that, iOS users and developers would be in big trouble by now.


This is a poor decision on Google's part. The end result is it tarnishes the Chrome brand.

Chrome's features like private browsing and tab/bookmark syncing are nice, but the defining feature of the brand IMO is that it is a very fast web browser. By linking the name to an app that will always be inherently slower than Safari on iOS, the brand is lessened with no significant upside.

I understand their desire to allow Chrome desktop users to have some meaningful interop between their desktop and mobile browsers, but I think they would have been much better served by not pretending this is an actual Chrome experience (much in the way Firefox allows some interop but keeps the distinction clear).


Download it and try it out -- to me, iOS Chrome seems much faster than Safari: http://itunes.apple.com/en/app/chrome/id535886823?l=nl&m...


I have to agree. The app itself feels very native (gestures, smooth animations) and browsing is fast too. It could be the absence of the blue bar on Mobile Safari, but webpages render instantly.


Apple will never allow a JIT Javascript engine on any app except their own, for security reasons.

(App Store apps can't allocate pages with the executable bit set, which is a good idea really.)


While that does, technically, "matter", it doesn't really matter to users. I've been using it for a few minutes and I too can confirm that it feels very, very fast. Which is all that matters. In fact, a few years ago, Mozilla confirmed that seeming faster is much nicer than actually being faster:

http://www.johnwaynehill.com/blog/2010/06/16/perceived-speed...

The point is, the Chrome guys executed well enough on their iOS app that the inherent performance issues really don't seem to be a problem (though I've only been using the app for about 5 minutes so my opinion is limited). And it's quite a pretty app. It brings just enough of the Holographic UI to look nice without looking alien on iOS. They did well.


I'm sure Microsoft could've used 10 excuses like that for IE back in 2000.


Also keep in mind it's using the Chrome networking stack, just not the rendering and JS engine.


Can someone clarify? I thought replacing the browser (actually even stronger: rendering web content using anything but the browser) was one of the items forbidden by the app store guidelines?


While Chrome for iOS will include a number of key features, including incognito mode and tab syncing across devices, the browser will still use Apple's WebKit-based engine required by the App Store developer guidelines. It also will lack the Nitro JavaScript engine that Apple uses to speed Safari's performance.


Which is why I still like Android as a mobile platform. Google gives users a choice, Apple makes you live within their walled garden.


V8 requires just-in-time compilation, which is not allowed on iOS for security-related reasons.


So, no V8 or Nitro, but Chrome/Chromium uses Webkit, so renders should be the same (just slower) right?


Well, Mobile Safari's webkit version will usually be somewhat behind the latest six-weekly Chrome release cycle.


The WebKit on iOS is rather different from all other WebKit ports in various ways (e.g. there are various -webkit CSS properties that are only supported by WebKit on iOS and not WebKit anywhere else). And of course there are lots of Chrome features.

So the renders may or may not be the same, depending. And various DOM features that are part of UIWebView won't be the same (e.g. any DOM or HTML feature that Chrome has but Mobile Safari does not will be missing).


  still use Apple's WebKit-based engine required by the App Store developer guidelines
This is pretty retarded, and should really be looked at by the DoJ. To hobble all web browsers like this is something that even Microsoft, at the height of their dominance, didn't even attempt.


Apple isn't dominant like Microsoft was, though (though I'll be honest that it looked for a year or two like they would be -- I'm still wiping the sweat from my brow over that). It's not enough to be anticompetetive under antitrust law, you have to be a monopoly too. Apple's hobbled third party browser environment isn't hindering android adoption, basically.


> I thought replacing the browser (actually even stronger: rendering web content using anything but the browser) was one of the items forbidden by the app store guidelines?

The real case is somewhat more complex:

1. It is not possible to replace the built-in browser (there are no hooks to have an other application handle e.g. `http` links), but it is perfectly possible to release (and sell) a "browser" application through which websites can be accessed

2. It is allowed to render any content, but it is not allowed to execute downloaded code save through the built-in interpreter, so a browser can't run javascript code locally. On the other hand, it's perfectly possible to have a "thin-client" browser and do all rendering on a remote server, that's what Opera Mini does.


It's still the system rendering and JavaScript engines.

Edit: Which, from the vast majority of users' perspectives, are functionally identical.


The "Request Desktop Site" button is the killer feature for power users.


I like how it doesn't just refresh the page, but the original you requested. So if you get redirected to a mobile subdomain and check "request desktop site" you'll get the original domain. Killer!


yeah, that's so far the best feature this app comes with.


It doesn't seem to let you set custom search engines, which is a bit disappointing. More options than Google, Yahoo, and Bing was one of the reasons I'd been hoping for this.

Even without that, the easily accessible incognito mode (Safari's is through the system wide Settings app), request desktop site, and bookmark sync is still worth more to me than Nitro/V8.

On the jailbreak side, Browser Changer doesn't support Chrome yet. Hopefully that will come soon.


I'd imagine custom search engines etc. will come soon. They just want to get it out there for now.


iOS Chrome requires iOS 4.3, while Android Chrome requires Android 4.0.

Ironically that means that 99% of the iOS users can use Chrome, while only 10% of the Android users can.


The icon is similar to Gmail on iOS - "wide" black margins. Any idea why?

Everything else seems to be working just fine, not slow or anything. The omnibox is really nice.


Your icons _must_ be (rounded) squares. You can't use transparency.


  (rounded) square side = 114px = 2*57
  tau=2pi
  area:= tau*r*r/2
  Chrome:    margin: 16px; radius: 41px = 57-16; area:=  840.5*tau
  Wordpress: margin: 12px; radius: 45px = 57-12; area:= 1012.5*tau
  Clock:     margin:  9px; radius: 48px = 57- 9; area:= 1152.0*tau
  Circle:    margin:  0px; radius: 57px = 57- 0; area:= 1624.5*tau
  
(Measurments taken from a screenshot on iPod touch "retina" resolution.)

So Chrome's circle area is 73% of Clock's and only 52% of the theoretical limit.

While I was playing with this I got inspired by Google+ for iOS and Metro and asked "What if it doesn't fit, but insead fills the (rounded) square?"

See for yourself. http://biserkov.com/pics/Chrome-on-iOS-icon-ideas.png

Blue circle radius: 21px; White circle radius: 25px

Disclaimer: I used the svg Chrome logo from Wikipedia. I'm no designer.


Probably in protest of iOS icon guidelines :P


Does it use it's own rendering engine or is it just interface on top of a UIWebView?


Vivian Li Cromwell from the Chrome team confirms that it uses the system rendering engine (presumably via UIWebView) and does not include the V8 JIT:

https://twitter.com/viviancromwell/status/218402587760795648


Well that's unfortunate. And didn't we learn last year that Apple left WebView twice as slow as the browser? Or did they fix that?


UIWebView is slower for security reasons. (Non-Apple) Apps aren't allowed to mark memory as an executable code space, which JITs require. Perhaps there would be some way for Apple to solve that for Nitro without introducing security concerns for all apps, but I'm not convinced.

I much prefer knowing apps can't surreptitiously create new executable parts of themselves.


I don't understand why they can't sandbox the UIWebView. That's how mobile Safari (presumably) is secured, as is Chrome. It has to render/execute untrusted content in any case.


Performance, probably. To sandbox it I imagine it would have to run in a separate process, and then you'd have to pass messages back and forth, which might be slow. But who knows.

It may be one of these things they were planning to do later, and then someone pointed out it would possibly be detrimental to what they want the iOS ecosystem to be, so they scrapped plans.


Message passing between a UIWebView is already one of the big complaints, requiring slow and klunky workarounds. To receive a message you detect URL anchor (#foo) changes in objective C. Sending is a bit better (inject a js string).

I wonder if its possible to sandbox a thread as opposed to a separate process. I doubt that Apple consciously neglects HTML5 app SDK functions. iOS has been the best platform for HTML5 for a couple of years already, supporting features (CSS 3d for one) that Android didn't.


They probably don't mind neglecting it for apps.


Apps on the store have to use UIWebView, which of course doesn't get the Nitro JavaScript engine.


Does this mean it will be slow as molasses on JavaScript-heavy sites?


They "have to"? I was under the impression that you had a choice of UIWebView and your own custom implementation. Are they really going to block sales of an app if it has an alternative JS engine?


You might be able to do your own JavaScript implementation, not sure, but I think actually not. (I stand corrected on this). But V8 definitely won't be permitted under the current laws, as it uses executable blocks of code in memory, which are not permitted, for security reasons under iOS.

Don't see that rule changing. Let's hope Apple let other browsers be the default though.


No, Apple's iOS developer agreements do not allow browsers with their own JavaScript engines:

"Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework."


Isn't UIWebView a component written by Apple? Why not include Nitro in it? Why would it be a security issue on Chrome but not on Safari? Do people have access to the UIWebView source code? If not, this "security" reason is BS.


Third-party processes on iOS cannot mark data pages as executable, which is a great security feature but it prevents JIT compilers or any other technology that dynamically generates machine code. Apple's built-in apps have an exception to this security mechanism, presumably because Apple is more confident in their own security auditing of those apps. Perhaps with some sandboxing mechanism and/or code auditing process they could allow some third-party apps similar access in the future, but it's not clear whether they feel a need to.


> Third-party processes on iOS cannot mark data pages as executable

Doesn't the UIWebView do that for you? And isn't it written by Apple? Why couldn't Apple make it use Nitro? Not sure where the security risk would be.


The restriction on executable pages is enforced by the kernel at the process level. This particular mechanism won't allow for enforcing diffeerent policiees for UIWebView code running in the same process as app code. If UIWebView could run JavaScript code in a separate process like Chrome then it might be possible.


I thought Safari implemented multi-process a long time ago, not on mobile?


So does this browser not automatically block third party cookies like the default Safari does?


If it's just a WebView with JavaScriptCore, what's the point? Is tab syncing the only benefit?


Its not JavaScriptCore, its webkit (UIWebView which is non-Nitro).

Tab syncing is one heck of a benefit, I can't wait to switch. Now I'm definitely going to stick with Chrome on my desktop, even though I'd been considering going back to Firefox. Quite disappointing on Apple's part that its only in iOS 6 that Notes and Calendar will be synced with OS X, still not Safari tabs.


Doesn't Safari on iOS 6 include tab sync? http://techcrunch.com/2012/06/11/safari-on-ios-6-to-feature-...


Thanks, I must've missed that in the wwdc keynote. I feel better now.


Months away. And I don’t think that’s really an argument against Chrome on iOS. Different people like to use different browsers on the desktop. If you use Chrome you don’t get tab syncing with mobile Safari. Also, some people might for example have an iPad and an Android phone. With mobile Safari, there is no way to sync tabs between the two. With Chrome there is.


Is JavaScriptCore not the WebKit JavaScript engine?

My point was that one of Chrome's main allures is V8, and if it's using stock WebKit (and therefore JavaScriptCore) there doesn't seem to be much point in using Chrome at all.


Well, both (desktop) Chrome and Safari are based on webkit, which I believe is the DOM rendering engine rather than the JS interpreter (nitro, v8, etc). Most users don't really care whats under the hood anyway, just that it works.


Seriously though, I can't get Chrome on my Android phone because it's stuck on Gingerbread but I can if I buy an iPhone. That makes loads of sense Google.



It's ridiculous that there are no debugging / console tools included. It's difficult for me to take this browser seriously as a web developer – especially when compared to Mobile Safari in iOS6.


Give them time, I'm sure they'll add that soon.

Although having to use UIWebView might constrain them.


I am disappointed that extensions are not supported.


I've fiddled around with it for 10-15 minutes and I love it. It feels much more responsive. Switching and creating tabs are much faster.

I'm on a 3GS


Does Chrome on iOS support WebGL?


Don't see how it can, as it's just a UIWebView.


UIWebViews can be configured to run WebGL, though this is not officially supported/sanctioned by Apple.


This requires calling a private API which means any app doing that will be rejected by the App Store.


Another workaround is to use JavascriptCore with openGL


Safari doesn't even officially support it yet, on iOS.


Just checked: No.


The headline should read Google Chrome Skin now works on iOS. For all intents and purposes, the heart of the browser, i.e the rendering and scripting engines are not running on the iPad or iPhone.

Would it be accurate to state that IE now works on the iPad if Microsoft ported the IE browser chrome(UI) to the iPad?


Note that Chrome on iOS does use the Chrome networking stack, which has a lot of enhancements - including SPDY.


But it still feels slower than Safari too me.


> The headline should read Google Chrome Skin

That would be redundant. Long before Google had a browser, the URL bar, buttons, scroll boxes, etc, of a browser (as opposed to the rendering engine) were called chrome.[1]

Developers didn't refer to browser skin, developers referred to browser chrome.

This is — quite literally in the original sense of the term — Google Chrome for the WebKit rendering engine.

1. "chrome: the browser UI around the web page" - https://developer.mozilla.org/Talk:en/Chrome


Google Chrome is built on top of WebKit, so this is rather Google Chrome for Safari.


As I understand it, Google's webkit went in another direction than webkit vanilla.


A browser is way more than a rendering engine. Even if this app was just a skin for UIWebView that incorporated Chrome sync and the look and feel of desktop Chrome, why not call it Chrome for iOS?


Eh, it's WebKit. Not quite the same WebKit, but close enough.

It's not like they are using completely different rendering engines.


There is no WebGL and other HTML5 features that Chrome has. Also, not only there is no V8 JS Engine support, but I suspect that Apple's NitroJS engine won't work in Chrome because it probably uses UIWebView to render sites.


Well, WebGL doesn't work in Chrome on Android either.


True, though that may change soon. And other features like SPDY are already working on Android but presumably not in Chrome for iOS.


Correction: Another comment here says that Chrome is using its own networking stack on iOS, so SPDY is working. However, there are still other differences between Chrome and Safari WebKit, like the Audio API.


Yeah, no WebGL's a bummer. But at least it is close to the same engine.


Come on. It's close to the same engine in the same way Desktop Safari is close to the same engine in Desktop Chrome. You upgrade one, the other remains the same.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: