Chrome for iOS nearly worthy of default browser status
At a Glance
Google’s Chrome browser for iOS is well made and a pleasure to use, particularly if you’re deeply entrenched in Google’s ecosystem. But owing to a few unfortunate limitations—many of them outside of Google’s control—it’s tough to recommend that anyone rely on Chrome as their main iOS Web browser.
Let’s start by highlighting the good features, and there are plenty of them. Chrome’s tab implementation, on both the iPhone and iPad, is excellent. You can quickly create new tabs, rearrange tabs, and flip among tabs. That last one you can accomplish simply by tapping the tab you’re after (on the iPad), or with a swipe from the edge of the screen. On the iPhone, that swipe navigates through one tab at a time; on the iPad, it instantly cycles through all of your open tabs—I know of no faster way to flip through tabs on iOS. It’s the equivalent of a keyboard shortcut for doing so on the desktop.
On the iPhone, tab navigation is superior to Safari’s offering: Tabs display in a vertically stacked list that’s quick to swipe through to find the screen you’re after.
Another compelling Chrome feature is its ability to sync your open tabs from other devices. If you log into Chrome with a Google account, you can quickly open tabs for pages that you visited in the Mac browser or in another mobile device. That’s a tremendously compelling feature for frequent device switchers. Apple’s promised iCloud Tabs—the same basic feature, sans Google—for Safari in iOS 6 and Mountain Lion, but Chrome, of course, is available now.
While Safari on iOS sports two fields—one for URLs and one for Web searches—Chrome on iOS, like its desktop counterpart, uses a single “omnibox” instead. If you type a URL into that bar, Chrome assumes you want to visit it; if you instead type a search term, Chrome searches for that instead. (The default search is unsurprisingly Google, though you can change it to Yahoo or Bing.) Google’s location bar also includes a microphone button that lets you perform voice-driven searches.
The one-field omnibar is a clever enough approach that Apple’s implementing it in Safari in Mountain Lion, too. But there’s a limitation to the feature on iOS: contextual keyboards. In Safari, when you tap into the URL field, you get a keyboard limited to characters useful when typing in such links: a .com button, and URL punctuation marks instead of the space bar. Chrome forgoes that keyboard in lieu of the regular text entry keyboard, supplementing it with some custom keys atop the main keyboard: colon (:), period (.), hyphen (-), slash (/), and .com.
That’s a reasonable approach, but it breaks with my muscle memory: I don’t expect to look up for the .com button, for example. And Chrome’s .com button isn’t as smart as the .com button everywhere else in iOS. Normally, if you tap and hold on that button, you get other common Web extensions (like .net, .org, and the like); Chrome’s button reveals no extra features of that sort.
Chrome’s suggestions in the location bar as you type are quite useful. The browser can autocomplete common URLs even if you haven’t visited them before—a significant bonus when you’re typing on the iOS keyboard. And, of course, it provides search suggestions just like the search bar on Google’s homepage.
Other clever features in Chrome include its button to switch to the desktop version of a website that’s serving up a mobile-optimized version instead, and its use of black-and-white Web previews in tabs whose content is cached and will be refreshed when you select them.
But despite all the good, it’s hard to recommend switching to Chrome full-time. Like the .com button flaw, some of the browser’s weaknesses are seemingly easy for Google to fix. One biggie: Its complete lack of any options for sharing (via email, tweet, or other means) the current webpage. Another is its lousy bookmark handling—bookmarks take two taps to access, and bookmarklets are annoying to access.
Some other issues, however, aren’t Google’s fault. Apple offers no way for users to set third-party apps as defaults—so you can’t set Chrome as your default Web browser. That means every link you tap in Mail, and every in-app button hardwired to open a link in Safari (say in a Twitter client or newsreader), will bypass Chrome. That leaves you with various unpleasant options: You can immediately copy links out of Safari and paste them into Chrome, or you can rely on both browsers depending on your point of entry. But in that latter scenario, you lose much of Chrome’s syncing advantage, since many sites you visit on your iOS device will have skipped that browser entirely.
Another Apple limitation on iOS prevents Google from using its own fork of the WebKit rendering engine and its own V8 JavaScript engine. The former isn’t a big problem; Apple’s own version of WebKit works great on iOS, and it means that Chrome gets the same smooth zooming options and rendering that you’d expect.
The JavaScript limitation is a bit more significant: Not only can Chrome not use V8, it also—like every other third-party app—is unable to use Nitro, the speedy JavaScript engine employed by mobile Safari. Instead, Chrome is limited to using a slower, older JavaScript engine that Apple makes available for third-party apps. The speed difference is not insignificant: Chrome for iPad completed the SunSpider JavaScript speed test in 5598.1ms; Safari needed just 1436.9ms in my tests. For light Web browsing, you may not notice the difference, but if you surf JavaScript-laden pages, the experience will feel notably slower in Chrome.
I like Chrome for iOS a lot. Its actual chrome—the user interface—is in many ways superior to Safari’s. Were I able to set it as my default browser today, I still probably wouldn’t. But with a few minor fixes from Google, I suspect users will be clamoring for Apple to make changing the default iOS browser an option.
