RemoteCompose: Cute or Crucial?

A couple of months ago, Google dropped some code for something called RemoteCompose. Google’s Nicolas Roard and John Horford spoke about it at droidcon London; the slides are available. RemoteCompose is in a pre-alpha state at the moment.

In one sense, RemoteCompose is like Glance. Glance uses composables to create app widgets. However, Glance does not support the full lineup of foundation composables; rather, it has its own foundation. That is because Glance composables generate a RemoteViews structure — a binary document that describes a UI and light interaction that can be passed across process boundaries.

Similarly, RemoteCompose has its own set of foundation composables and related tooling. RemoteCompose composables generate a binary document that describes a UI and light interaction that can be passed across process or machine boundaries. So, whereas Glance is mostly aimed at app widgets and some Wear OS elements, RemoteCompose composables could be played on non-Android targets.

The roster of capabilities is impressive. In some parallel universe, RemoteViews got all these capabilities, courtesy of continued Google investment in that bit of technology.

John and Nicolas offer up interesting possibilities for this technology, from the semi-conventional (server-defined UIs) to the mind-blowing (composables delivered via NFC tags or QR codes). I could also see this being used for stuff like Android Auto (phones delivering UI to the dashboard) or Android Automotive (e.g., via a binary document player for an RTOS powering the instrument cluster).

So, it seems slick.

However, this is where I need to raise warning flags. Google’s past is not conducive to this sort of future.

The two technologies that RemoteCompose reminds me most of are Instant Apps and slices. Instant Apps was strategic for Google… until it wasn’t. Developers who invested in Instant Apps got some benefit for a modest period of time, but that’s it. Any firms who relied on Instant Apps got screwed in the end.

Slices are an even closer comparison. While you may not remember slices, they were an API for building a binary document that described a UI and light interaction that could be passed across process or machine boundaries. In practice, Google only advertised cross-process use, but they had code that hinted at cross-machine use. Slices were not simple, but they were far simpler than what needs to go into RemoteCompose. And slices lasted about a year before Google abandoned the initiative, despite slices being promoted at Google I|O and trumpeted in an Android release.

So, before I invest a lot in RemoteCompose beyond cute demos, I will want to see some strong signs that RemoteCompose will be usable in a decade or more, such as:

• Does JetBrains publicly “get on board” and start pushing RemoteCompose, so RemoteCompose is not dependent entirely upon the whims of Google?

• Is Google itself becoming reliant upon RemoteCompose for certain products and services outside of the Android team?

• Does Google publish (and show signs of maintaining) a clear specification for the binary document format?

• To what extent does Google encourage outside contributions to the document player ecosystem, both to their own players and in creating independent players?

• Does RemoteCompose show signs of migrating from Google control to control by a semi-independent working group, or even to a standards body?

PDF is a great comparison point. Had it been just the work product of a few Adobe engineers back in the day, it might not have lasted. But Adobe published specifications and eventually transferred control to an ISO committee as part of a standardization effort. Getting to that standardization took nearly two decades, but the specification and (possibly grudging) support of external PDF renderer implementations were signposts indicating that PDF was more than “a flash in the pan”.

I am sorry if I am sounding negative about RemoteCompose. I have been looking forward to something like this for a long time, and it genuinely is exciting to me to see RemoteCompose being worked upon. It’s just that the graveyard is filled with headstones, and savvy developers and firms need to take that into account.