Chrome for iOS doesn't use V8 or the Chromium fork of WebKit, just UIWebView. [0] Because it's using WebViews, it's about 3x slower than the OS's Safari browser [1], because WebViews in sandboxed apps don't get the "Nitro" JavaScript JIT from iOS 5 onwards (presumably for mark-executable security reasons).
Unless the tab-sharing feature is crucial to more people than I thought, I don't think this app is going to be a runaway hit.
Only JS execution is 3x slower -- everything else (DOM, layout, repaint, parsing) is the same.
Most web pages (and even web applications) are rarely bottlenecked by JS execution speed. (There are a few exceptions to this rule...for example, the JS GameBoy Color emulator probably won't work very well)
You mean the same as Mobile Safari, not the same as Chrome, right? Because "repaint" is not part of WebKit proper (it's implemented separately in Chrome and Safari, for example). And even "layout" is different code on iOS and in other WebKit ports...
A crucial feature for me would be password-manager support (lastpass, 1passwd). The (lack of) password management on the iPad is driving me nuts. The half-baked external apps that let you copy/paste don't cut it for me. Nor the awfully slow and constantly crashing "LastPass browser".
Safari 6 added a new preferences panel for saved passwords. Unfortunately there's not an equivalent iPad setting (just checked on iPad 2, iOS 6 beta 1), but this might change between now and fall...
I didn't have much success with the bugs that I filed at apple over the past years. They all went into a black hole, never received as much as a response.
The thing is that I don't want the iPad to just save passwords. It already does that, although somewhat unreliably for me. I want it to use my existing, ginormous list of passwords stored in LastPass.
I don't even try anymore to do anything that requires a login on the iPad, it's an exercise in frustration. Sometimes Safari remembers the password that I painfully transcribed for a site, usually it doesn't.
It's such a blatant oversight for a device that is touted no least as "the internet in your hands" that I keep wondering why I so rarely see other people mention it.
It's such a blatant oversight for a device that is touted no least as "the internet in your hands" that I keep wondering why I so rarely see other people mention it.
I was with you up until this last sentence. People who know what LastPass is (let alone use it) are in a tiny minority.
Given how they treat the development community (hello Xcode nightmare), which I'd wager is a much larger group, I don't think it's entirely surprising that something like password manager support would be further down in the list of priorities.
Agreed. 1Password support would be the thing that would cause me to use Chrome exclusively on iOS. The machinations I have to go through now with 1Password on iOS are extremely frustrating.
I have the same problem and found a solution, maybe it helps for you.
1password supports Dropbox integration, and it provides a web page inside your dropbox account (i.e. password protected) that you can log into with your master password to check them out.
It is not automatic nor integrated, and it does not allow you to add new passwords, but at least you can easily copy and paste them on the iPad.
Only for Javascript stuff, though. If you're browsing mobile sites, it shouldn't affect you at all, as well as most websites on the web that aren't JS-heavy.
Don't worry too much about that, it's only slower for javascript execution. The other features, including Chrome sync, unlimited tabs, "Request desktop site", more than make up for it.
The real stumbling block, IMO, is that without jailbreaking, links from other apps will always open in Safari.
I'm not sure what happens when multiple apps register for the same scheme.
I'm looking for a generic mechanism to let the user choose an app and pass an 'http' url to that app. I don't think I can do that with custom schemes, because each app would have its own scheme.
It could be accomplished via a custom file type if everybody standardized on it (say via a .url file of type text/x-url or maybe even text/plain). But I was hoping for something official.
The current way people do this is via the pasteboard, but the switching and pasting process feels awkward to me. I suppose that may be the best solution for now. Maybe apps should just handle things better if they're awoken with a new URL on the pasteboard (i.e. offer to take an action with it).
The first app or the last app (can't remember which) that registered for the custom URL scheme owns it.
> Maybe apps should just handle things better if they're awoken with a new URL on the pasteboard (i.e. offer to take an action with it).
This is almost how using custom URL schemes would work, but I think it's still superior to fiddling with the pasteboard though.
But you are right. There isn't a standard way to do it now. Most apps that expose or utilize this form integration has to come up with something themselves. Also see http://handleopenurl.com/
Safari on the iPhone in iOS 5 only gets 8. I wonder if Chrome for iOS gets any sort of tab recovery on crashes. It doesn't happened frequently, but it's annoying when I have to quit and relaunch safari for whatever reason and lose everything I had open.
The bummer here for Google (and anyone else who'd like to provide an alternative to Apple's apps on the iOS platform) is that there's no way to set your default browser. Or email client. Or calendar. It'll be hard to use chrome if Safari opens up every time I click a link in email or any other app.
I wonder if Apple is ever going to run into legal trouble for this - it can't be much different than Microsoft's troubles with bundling IE, WMP, etc. on the desktop.
It is a bummer you can't make Chrome your default browser. However, if you move Safari to a folder and put Chrome in your launch bar, Safari being default won't bother you too much.
I have high hope for Chrome for iOS to be like the Google Search app[1] which is simply fun to use. Instead, on an iPad, what we got is just a desktop UI slab on top of touch interface… and seems to trash old tab faster than Mobile Safari. It's kind of sad.
Edit: I was wrong about tab trashing, seems like old tab reloads when you come back from Incognito mode.
This could be a nice "trojan horse" into the iOS ecosystem. Get Apple users hooked enough on Chrome, that they will want to switch to Android for the "real Chrome experience". I know a lot of people are not using iPhones because they can't live without the Gmail app for Android.
It's possible but I seriously doubt users would switch to Android because of a browser. Especially when they've already spent a lot of money on iOS apps and are familiar with the iOS ecosystem. I also doubt any mainstream user will understand that Chrome on iOS is slower than it could be because of Apple's rules.
> It's possible but I seriously doubt users would switch to Android because of a browser. [..] I also doubt any mainstream user will understand that Chrome on iOS is slower than it could be because of Apple's rules.
Yes, it seems more likely that the opposite of what GP said will happen: iOS users will try Chrome, and seeing it is 3-4x slower than the default Safari, will assume that Chrome would be slow on Android too - it has the exact same name after all - so they'll stick with iOS.
I'm more curious to see if Google, or users, will try to use the Chrome launch on iOS as a wedge into getting Apple to open up the OS to allow alternative defaults than Apple's own.
Autocompletion in the omnibox is way more aggressive than in Safari. You typically only need to type one or two characters to get to the sites you visit most frequently. In a lot of cases, this will more than make up for any JS performance differences between Chrome and Safari.
On my 3gs Chrome is showing some significant slowdown over Safari, in JS, page loads, and scrolling - all are delayed. The reasons have already been explained, but it is still sad. The omnibar makes it worth it though, gosh I have missed thee.
It's bizarre. Why is a Google app using an application specific password instead of your authentication code? The only reason an app should not use the two factors is if it's some legacy protocol that only takes a single userid/password pair. WTF.
Google's own apps should really support 2-factor auth, and they should improve the flow for app-specific passwords.
The flow for getting an app-specifc password is awful. It takes a large number of clicks (I think 7, but I lost count), and several of the pages are confusing. Not only that, but you have to enter your password and a name of the app. Ideally, it would be a reduced number of clicks (like 2–3), entering your password, and that's it. Adding a name for the app should be optional. My apps all have names like “alsjdlajshd” or “9”, because I'm impatient, and the likelihood that I'll ever need to invalidate one is low enough that I would be okay with just invalidating them all.
The lack of an OmniBox is what disturbs me the most about Safari on iOS right now. The most common use case being entering one of the boxes, realizing I don't have the URL in my head and need to search (or vice versa). Also, Chrome's OmniBox let's you search your history at the same time as you search the web and enter URLs... priceless.
2. Do you use 2-factor authentication? I do, and so I'm used to seeing this on applications that don't fully support the 2-factor authentication, which is, I assume why it was asking.
After using it for a while now it's made me realise there's a ton of features I've been missing when using mobile Safari:
-New tab with Most Visited and Recently Closed
-Google Sync for bookmarks but more importantly it instantly empowers my Omnibox
-the keyboard has an extra character row at the top that includes hyphens (simple but nice)
-Swipe between tabs
-find in page
-Open in new tab defaults to opening in the background (I've missed this a lot)
-unlimited tabs
I realise some of these aren't unique to mobile Chrome but as far as I'm aware they are missing from mobile Safari and they're the reasons I'll be sticking with Chrome.
Yes, it’s very strange (and annoying) that it doesn’t disappear. With the swipe-to-switch-tabs gesture, there’s even less reason to show it permanently than in Mobile Safari.
Can someone please explain Apple and Microsoft's insistence to push Safari and IE respectively? It seems that they have little to gain.
In this case, why does Apple mandate the use of UIWebView instead of allowing a native implementation of Webkit+V8? It just seems like Apple is being stubborn as usual.
finally a solution to open more than 10 tabs. I was quite excited to have a way to open those 30+ news to read while traveling on the underground.... sad news, when I switch tab the browser reload the page and lose the content... wtf! back to safari :(
Unlike on Android, where pushing an app live is almost instantaneous, on iTunes it takes 24 hours for apps to propagate through all the various content distribution nodes.
It's much more likely it's this, since knowing Apple's review teams I would strongly suspect when they saw the "Google Chrome" app in the review queue they raised it up the management chain.
There is no rhyme or reason to this, it's just how it goes in the crazy world of iTunes Connect and the app store.
Can't imagine the amount of arm twisting that was involved in getting this into the App Store. Must've really come down to the ultimate "No Google for you" argument.
Not an answer, just an elaboration on differences: Apple doesn't allow "duplicating functionality" or something along those lines and as other comment already mentioned, Chrome is a stock browser with different UI. That's also why there is no Opera Mobile on iOS. Opera Mini on the other hand bypasses this rule by being application which shows already preprocessed web (similar to Turbo function on Desktop or Mobile).
Unless the tab-sharing feature is crucial to more people than I thought, I don't think this app is going to be a runaway hit.
0: https://twitter.com/viviancromwell/status/218402587760795648 1: https://twitter.com/stroughtonsmith/status/21843446275153920...