Apple's Handoff technology is one of those cool conveniences you have to experience. But it's by and large an Apple-only phenomenon, running exclusively on Lightning-equipped iOS devices and 2012-and-later Mac models, mainly on a selection of Apple's built-in apps. Apple has kept the APIs to its iOS and OS X operating systems, and apps can hand off content and state only to the same app on another devices using the same iCloud account.
Thus, when Google adopted Handoff this week in the latest version of its Chrome browser for iOS, I was intrigued. Apple lets any developer use the Handoff APIs in its OSes, so the technology is used by other companies' apps. But Chrome on iOS can hand off information to Safari on a Mac -- ignoring the app restrictions of the Handoff API.
Was this a harbinger of a looser Handoff policy? I hoped so, but the more I dig into the new Chrome browser, the less sure I am.
As intended, Handoff lets Apple devices within Bluetooth signal range broadcast when a Handoff-capable app is running, and the other devices provide the option of transferring that app's current contents and states for the user. Thus, you could start composing an email on your iPhone and pick it up in progress on your Mac as long as you have the same email client on both devices.
But with Chrome running on an iOS device, your other devices (iOS and OS X) show Safari as the source of the handoff, not Chrome; if you pick up a Web page, the other devices open Safari, not Chrome. I could not get Chrome to hand off Web pages to Chrome on other iOS devices, only to Safari.
I suspect the reason is that Apple forces all browsers to use its WebKit browser engine in iOS; when you run Chrome, you're really running Safari with a different front end. Thus, the handoff is not from Chrome to Chrome but from WebKit to Safari.
Mainly, anyhow -- you still need Chrome on the iOS devices for Handoff to offer a transfer; nothing happens if Chrome is not installed on all the devices. There is some communication between the Chrome apps via Handoff, even if actual work is done by Safari.
It gets weirder when a Mac gets involved. When you run Chrome on an iOS device, an in-range Mac sees the Chrome instance and offers to use Handoff to transfer the current Web page. It shows your default browser, which you set in the General system preference in OS X. If your default Mac browser is Safari, the handoff is from Chrome in iOS to Safari in OS X. If your default Mac browser is Chrome, Chrome in iOS hands off to Chrome in OS X.
No matter what your default browser on the Mac, Safari in iOS hands off to only Safari in OS X.
Finally, I could not get Chrome in OS X to hand off to Chrome or Safari in iOS -- Handoff seems to work in only one direction for Chrome in an iOS-OS X workflow. But Handoff is an omnidirectional protocol, so the handoff should work from computer to mobile device, not merely from mobile device to computer.
Again, some communication is going on between the Chrome instances, but an intervening element makes Chrome not act like a typical Handoff app. I suspect Apple's requirement that iOS browser apps use WebKit has caused a distortion in the standard Handoff APIs that Google has partially addressed, but not fully.
A bug fix issued the next day didn't change the off Handoff behavior in Chrome. I asked Google what was going on. A spokeswoman assured me that iOS-to-OS X handoff worked as designed, but that was not one of the issues I had reported. It's in every other workflow where Google Chrome's Handoff doesn't work like Handoff should.
This curious behavior could simply be the result of a hack in Chrome to enable handoff support or a hack in WebKit's Handoff support in third-party iOS browsers.
But it also shows that perhaps Handoff could be a little more expansively implemented, allowing handoff across different apps, such as from Chrome to Safari or Word to Pages. For now, Chrome's Handoff behavior is the odd man out, so I wouldn't hold my breath for other cross-app handoffs. But I can still hope.