Getting your app to support Web Intents on Chrome

Chrome just got Web Intents support in Dev and Canary builds (18 onwards). This is a huge milestone and I am very excited by this first step along the path of building a more connected web of apps.

A lot of developers have asked me how to get started as it seems some of the demos on http://demos.webintents.org don't register correctly. I have a good answer for that - in short: Chrome doesn't yet detect the intent tag, instead applications currently can only register their support for an action such as "share" via the Chrome apps manifest.

The longer version is a little more complex:

Consensus over the introduction of a new tag in to the spec has not yet been reached.
Working with members of the DAP in the intents task force, it is clear that discovery of applications and services shouldn't only take place by detecting a tag on a web page. What happens if the service you want to "Share" a video too is a TV connected to your local network? Or an external native application wants to be able to support a "Save" action. To enable this important use case the User Agent should be able to determine the services it presents to users, and this is why this is allowed in the specification (3rd paragraph).

Bringing this closer to home, because the discovery and presentation of an app's capabilities can be managed by the User Agent, and Chrome has the concept of extensions and installed apps we can quickly enable the intents feature by letting developers declare their support for actions in the manifest.

So what does the declaration in the Chrome apps/extension system look like? It is pretty easy, it is an entry into the manifest called "intents". It looks like:

{ "name": "Share to Gmail™", "version": "0.0.0.2", "icons" : { "16" : "favicon.ico" }, "intents" : { "http://webintents.org/share" : { "type" : ["text/uri-list"], "title" : "Share to Gmail", "path" : "/launch.html" } }}

It is that simple. The intent section includes a dictionary of supported action (http://webintents.org/share) and in each action object there is an array of data types that the application or extension can handle, the friendly name to appear in the picker and a path to what should be opened when the user selects your app. The client-side code remains exactly the same as it would in a normal web app.

In the long term we want applications to be able to declare their capabilities and services directly through their html and this will be done with the Intent tag. However whilst the standardisation work continues we want to make sure that developers today can start building apps that can take advantage of the Web Intent system.

A lot more examples can be found on the Web Intents Github repository.

Expect a lot more posts about how to build applications that love each other with Web Intents.

View Source | Make a correction | Correction history

I lead the Chrome Developer Relations team at Google.

We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.

Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.

I love to learn about what you are building, and how I can help with Chrome or Web development in general, so if you want to chat with me directly, please feel free to book a consultation.

I'm trialing a newsletter, you can subscribe below (thank you!)

Mastodon Book a consultation

See Also

Tags