Chrome for iOS was historically kept separate from Google’s open-source Chromium project. Chrome uses a rendering engine called Blink on every platform except iOS where it must run WebKit. That made incorporating Chrome for iOS into Chromium complicated, but today Google announced that Chrome for iOS has rejoined Chromium and been added to the open-source repository. Now,
developers can compile the iOS version of Chromium like they can for other versions of Chromium. Development speed is also faster now that all of the tests for Chrome for iOS are available to the entire Chromium community and automatically run any time that code is checked in.
In an update released today, Google has added a widget and new gestures to Chrome for iOS, making it easy to open links from other apps and manage tabs on the iPhone. I’ve been testing this new version of Chrome for the past couple of weeks, and I think Google is bringing some interesting ideas to the table.
Kevin C. Tofel, writing for Gigaom:
Google’s strategy to use the Chrome browser as a desktop replacement took another step forward on Friday. Users of Chrome Canary, an experimental version of Google’s browser, can now associate Mac files with supporting Chrome apps in the Finder. This means that instead of opening a basic text file with the native OS X TextEdit, you can open it with a Chrome app like Text, Caret or Simple Text.
Interesting move from Google, but not a surprise either. Google has been building an ecosystem of apps on iOS for over a year, and it's only obvious that they're going to continue extending the effort to OS X, where they have even less limitations.
On iOS, they redirect YouTube links to the YouTube app, leverage x-callback-url for Chrome, and make sure you always use Google apps when opening links; on OS X, the Finder's “Open With” menu makes perfect sense to redirect users to Chrome – especially for Office-type documents.
Two weeks ago, I covered CloudyTabs, a free Mac app to access Safari's iCloud Tabs from the OS X menu bar. For those who wished to have a more integrated solution for Google Chrome on the Mac, Thundercloud is a simple extension that, like CloudyTabs, reads Safari's iCloud Tabs and puts them in a popover. There are a couple of configuration steps to get the extension to work with Chrome, but they're explained upon installation and they're easy to follow.
My problem: I haven't installed Flash on my Mac and I sometimes need to watch YouTube videos that require Flash Player in Google Chrome. Google's browser is my Flash shelter: Safari is my main browser and I only keep Chrome around for Flash videos. I was getting annoyed by the process of copying a URL -> launching Chrome -> pasting the URL, so I made a simple Keyboard Maestro macro to automate everything with a hotkey. I don't know what took me so long.
The macro checks if Safari is the front window, and, if not, it displays a notification with an error message. I do this to prevent accidental hotkey presses for URLs that I don't want to open in Google Chrome. If Safari is the front window, however, what required a bunch of steps in AppleScript to open the current Safari URL in Chrome is a single action in Keyboard Maestro: Set Google Chrome URL, using
%SafariURL% as a variable.
The two additional steps -- Open Chrome and Wait For Chrome To Finish Loading -- were necessary because I discovered that, when launched with a Set URL action, Chrome wouldn't intercept the URL sent by Keyboard Maestro and would simply display a blank tab. In this way, Chrome is launched, paused for a second as it reloads open tabs or the start tab, and then the Safari URL is opened in the current tab. If you want to open the URL in a new tab, change the Set Chrome URL action to New Google Chrome Tab.
You can download the macro here.
I guess you could say that I was quite the fan of Google Chrome.
Before switching to Chrome last year, I didn’t have a “favorite” browser or “browser of choice”: I just kept jumping between Safari, Chrome, and Firefox, trying out all the features that the three major players had to offer on OS X. I’m pretty sure that, at one point, I even tried to go a full week with using Opera. My browser requirements have always been fairly standard (several open tabs; a lot of reading; sync with mobile devices), so I could afford to change browsers without having to worry about setting up a complex environment from scratch.
As I started using my iPad as my primary computer last year, I was growing increasingly annoyed with the state of iCloud sync in Safari and lack of major overhaul to a design that originally shipped with iPhone OS 1. I don’t frequently abandon systems that work for me due to stagnation, but iOS 6’s Safari exhibited a certain staleness on top of issues with bookmark and tab sync that, for me, were becoming an annoying problem. I liked Safari’s speed and native integrations with iOS, but it was prone to errors and boring.
On the other hand, Google Chrome for iOS was promising, familiar, and power user-friendly. I fell in love with Google’s support for x-callback-url, which I integrated in several workflows of mine as it allowed me to save time when switching between apps on my iPad; sync was nearly perfect; I praised Google’s superior implementation of voice dictation and feedback, although I noted how their Voice Search couldn’t exactly compete with Siri. Google kept pushing updates to Chrome for iOS, making it a capable browser for average and power users alike.
A few weeks after publishing my review of iOS 7, I decided to uninstall Chrome from all my devices and move back to Safari as my main and only browser on my iPhone, iPad, and two Macs.
I’m not looking back. I’m happy with the new Safari – so much, in fact, that I’m even considering Reading List as my “read later” service going forward.
Yesterday saw the release of thousands of apps optimized, enhanced, or, in some cases, completely redesigned for iOS 7. At MacStories, we highlighted several apps that were ready for the OS’ rollout such as Pocket, OmniFocus 2, or Instacast 4, and then we fired up iTunes – or simply waited for automatic updates to do their magic on iOS 7 – and checked out all the other apps that were also released yesterday. In this post, I thought I could offer a quick overview of iOS 7 updates from four big-name companies: Twitter, Facebook, Yahoo, and Google. Read more
Released earlier today on the App Store, Chrome for iOS version 29.0.1547.11 (according to Google's release notes) brings various search and navigation improvements, as well as a new white-themed icon that seems to be aimed at making Chrome fit more with the upcoming aesthetic of iOS 7.
The first improvement is better handling of single sign on with other Google apps for iOS, something that the company has been focusing on lately to provide an even tighter integration between its apps for iPhones and iPads.
Alongside bug fixes and stability improvements, Google has added a way to more easily swipe back from a webpage to search results: when you search on Google and choose a result, when you go back to your search query you'll see a new animation and, more importantly, your previous results instantly appear on screen. Switching back and forth between results was cumbersome in the old Chrome, as it wasn't fast and often led to problems with the Google Search page reloading again.
Last, Google says that Voice Search has been enhanced with pronoun support for chaining queries like "Who is Barack Obama?" followed by "Who is his wife?". in my tests, the feature worked as advertised with US English Voice Search, correctly displaying results for the aforementioned person/wife combination, as well as "What is the capital of Italy?" and "What is its population?". However, improved pronoun support doesn't seem to be working with Italian yet, which wouldn't be surprising considering that Google rolled out international versions of Voice Search months after the US launch.
You can get the latest Chrome for iOS update on the App Store.
I don’t like it when third-party apps or services force me to share links to articles or webpages using their own custom shortened links. I understand the appeal of personalized short domains – after all, we tweet mcstr.net links with the @macstoriesnet account – as they can provide analytics to track clicks, can save characters, and, at least in theory, they “look cool”. However, I’ve been long considering the idea of dropping our mcstr.net links, but I think the issue is worse (and more annoying) for apps and services that don’t tweet links to their own content (like we do) but that override others’ links with different domains. An example is Pocket, which gives you the clean, original URL when you choose the “Copy Link” action from the sharing menu, but that instead returns pocket.co links when sending text to Drafts (which I do often). I’ve grown tired of this practice (in Pocket and other services), and I’ve put together a workflow based on a Python script that allows me to easily resolve short links without having to open the browser and tap on multiple menus. Read more