When Apple debuted its Handoff technology in 2014's iOS 8 and OS X Yosemite, I was excited by the notion of liquid computing, in which both data and application state move from one device to another as you do. Apparently, the technology didn't excite many others, as it's rarely implemented outside of Apple apps, and most users aren't aware of it, unless perhaps they happen to have an Apple Watch.
Now, as announced last week at the Build 2016 developer conference, Microsoft is prepping for the release of Project Rome APIs for Windows PCs and smartphones, and -- having largely given up on owning the mobile platform -- it plans to release SDKs for iOS and Android, though not for OS X, since Microsoft remains unwilling to accept its decline on the desktop.
Project Rome is both similar and dissimilar to Handoff, and those differences perhaps will help it gain broader adoption than Handoff has attained.
Before I explain how the two compare, I should note that Microsoft previously introduced some cross-device capabilities in Windows 8. But those are more like Apple's other, older Continuity services managed via the cloud, such as syncing bookmarks and settings across devices tied to the same account.
Apple's Handoff and Microsoft's Project Rome are about federating apps across multiple devices, not simply syncing metadata. In Apple's case, that means recent models of Macs, iPhones, iPads, iPod Touches, and Apple Watches running iOS 8 or OS X Yosemite or later. In Microsoft's case, that means Windows PCs and Windows Phones running Windows 10 or later, as well as iOS and Android devices whose versions have yet to be revealed.
What Apple's Handoff does
Handoff is focused on, well, handing off an application state from one device to another. For example, if you are composing an email in the Mail app on your iPhone and you get near your Mac, the Mac will see Mail running on your iPhone and offer to transfer that in-progress message from the iPhone to the Mac, launching Mail on the Mac in the process.
The devices detect each other via Bluetooth and Wi-Fi Direct, and they automatically pair if they use the same Apple ID (and if Handoff is enabled, of course).
What's key is that Handoff relies on the receiving device to make the transfer happen; the idea is that the user has moved to a different device and wants to pull in what he or she had been working on previously. It's not about controlling another device.
The most common uses of Handoff that I see in the real world are with the Apple Watch and with the iPhone. The Apple Watch can pick up phone calls, text messages, and email messages from the iPhone using Handoff. And a Mac or iPad can answer a call on an iPhone or interact with a text sent to an iPhone, via Handoff.
I don't think many people use Handoff to transfer data between apps, such as in my Mail example, across Apple devices. Partly, that's because OS X makes it easy to detect a potential Handoff, but the notification feature is all but invisible on iOS devices, so it's harder to feed the habit.
What Microsoft's Project Rome does
Microsoft's Project Rome could be used to develop Handoff-like interactions. However, from Microsoft's demos, it appears that the operational model is more like remote control, where the first device initiates the interaction with the second device, contrary to Handoff's approach in the second device initiating the transfer that's offered quietly in the background as long as there is a connection. Also, Project Rome is more generalized than Handoff, offering several types of interactions.
First, it can detect devices both locally over Bluetooth or Wi-Fi and elsewhere via the Internet -- not only locally as in the case of Handoff. Thus, it's useful for some remote desktop-style uses, such as pulling info from your office computer when at a conference or sending a presentation to a computer in another location.
Second, the APIs are aimed at a range what Microsoft calls "app experiences," using a combination of app-launching protocols and communications payloads.
There are APIs for launching an app on another device, along with a Uniform Resource Identifier (URI), to know what content to pull. The notion here is if a user has, say, the Facebook app installed, clicking a link to a Facebook post should open the post in the Facebook app, not at the Facebook website in a browser. The URI is essentially used like an anchor tag would be on a website to figure out what item to display. Via settings, users can control whether such links open the app or the website on a per-app basis.
There are APIs to extend an app interaction to other instances of the app on other devices. For example, you might run an app on your phone, then have it launch on your desktop as well, so you have both apps active and interacting. An example is watching a movie on one device and interacting with a related trivia game on the other based on what part of the movie you are currently watching. This is different than Apple's AirPlay or Microsoft's WiDi screen mirroring, which simply sends the screen to another device -- in Project Rome, the app runs on both devices and the two instances can communicate with each other.
There are APIs to remote-control an app across devices. Apple's Keynote and Microsoft's PowerPoint can already do that, letting you manage a presentation on your laptop or tablet from your phone or (in Apple's case) watch. With Project Rome, Microsoft provides a widely available API for the task, not rely on custom code developed for each app as in the case of Keynote and PowerPoint.
The advantages of Project Rome
Compared to Handoff, the Project Rome approach is broader and not wholly locked into a single vendor's ecosystem. (We'll see if Microsoft actually treats iOS and Android as equal citizens, of course.) Project Rome also handles more potential use cases than Handoff does, which may increase developer adoption of the technology. Those two aspects should give Project Rome an advantage over Handoff.
But from what Microsoft has shown so far, Project Rome could also be complex to develop, precisely because it can cover many tasks and handles both local and remote connections. Fortunately, Project Rome extends several existing Windows 10 APIs, so Windows developers can build on what they already know from Windows 10.
With Project Rome, I'm cautiously optimistic that Microsoft may realize the liquid computing notion more broadly than Apple has.