The Web Share API in Safari on iOS

I implemented the Web Share API over on The Session back when it was first available in Chrome in Android. It’s a nifty and quite straightforward API that allows websites to make use of the “sharing drawer” that mobile operating systems provide from within a web browser.

I already had sharing buttons that popped open links to Twitter, Facebook, and email. You can see these sharing buttons on individual pages for tunes, recordings, sessions, and so on.

I was already intercepting clicks on those buttons. I didn’t have to add too much to also check for support for the Web Share API and trigger that instead:

if (navigator.share) {
  navigator.share(
    {
      title: document.querySelector('title').textContent,
      text: document.querySelector('meta[name="description"]').getAttribute('content'),
      url: document.querySelector('link[rel="canonical"]').getAttribute('href')
    }
  );
}

That worked a treat. As you can see, there are three fields you can pass to the share() method: title, text, and url. You don’t have to provide all three.

Earlier this year, Safari on iOS shipped support for the Web Share API. I didn’t need to do anything. ‘Cause that’s how standards work. You can make use of APIs before every browser supports them, and then your website gets better and better as more and more browsers add support.

But I recently discovered something interesting about the iOS implementation.

When the share() method is triggered, iOS provides multiple ways of sharing: Messages, Airdrop, email, and so on. But the simplest option is the one labelled “copy”, which copies to the clipboard.

Here’s the thing: if you’ve provided a text parameter to the share() method then that’s what’s going to get copied to the clipboard—not the URL.

That’s a shame. Personally, I think the url field should take precedence. But I don’t think this is a bug, per se. There’s nothing in the spec to say how operating systems should handle the data sent via the Web Share API. Still, I think it’s a bit counterintuitive. If I’m looking at a web page, and I opt to share it, then surely the URL is the most important piece of data?

I’m not even sure where to direct this feedback. I guess it’s under the purview of the Safari team, but it also touches on OS-level interactions. Either way, I hope that somebody at Apple will consider changing the current behaviour for copying Web Share data to the clipboard.

In the meantime, I’ve decided to update my code to remove the text parameter:

if (navigator.share) {
  navigator.share(
    {
      title: document.querySelector('title').textContent,
      url: document.querySelector('link[rel="canonical"]').getAttribute('href')
    }
  );
}

If the behaviour of Safari on iOS changes, I’ll reinstate the missing field.

By the way, if you’re making progressive web apps that have display: standalone in the web app manifest, please consider using the Web Share API. When you remove the browser chrome, you’re removing the ability for users to easily share URLs. The Web Share API gives you a way to reinstate that functionality.

Have you published a response to this? :

Responses

john holt ripley

“if you’re making PWAs that have display: standalone, please consider using the Web Share API. When you remove the browser chrome you’re removing the ability for users to easily share URLs. The Web Share API gives you a way to reinstate that functionality” adactio.com/journal/15972

john holt ripley

“if you’re making PWAs that have display: standalone, please consider using the Web Share API. When you remove the browser chrome, you’re removing the ability to easily share URLs. The Web Share API gives you a way to reinstate that functionality.” adactio.com/journal/15972

2 Shares

# Shared by Michael Spellacy (Spell) on Wednesday, October 16th, 2019 at 1:50pm

# Shared by jkirchartz on Wednesday, October 16th, 2019 at 2:26pm

5 Likes

# Liked by Aaron Parecki on Wednesday, October 16th, 2019 at 11:48am

# Liked by Dominik Schwind on Wednesday, October 16th, 2019 at 12:27pm

# Liked by Michael Spellacy (Spell) on Wednesday, October 16th, 2019 at 1:56pm

# Liked by Kam on Wednesday, October 16th, 2019 at 4:01pm

# Liked by Lucid00 on Wednesday, October 16th, 2019 at 5:54pm

Related posts

Add view transitions to your website

Enhance your website, progressively.

Audio

The sound of worlds colliding.

Implementors

Different browser vendors have different priorities.

Code print

Print stylesheets and QR codes: one great flavour and one yucky flavour that taste quite good together.

Declaration

HTML. JavaScript. Why not both?

Related links

Pivoting From React to Native DOM APIs: A Real World Example - The New Stack

One dev team made the shift from React’s “overwhelming VDOM” to modern DOM APIs. They immediately saw speed and interaction improvements.

Yay! But:

…finding developers who know vanilla JavaScript and not just the frameworks was an “unexpected difficulty.”

Boo!

Also, if you have a similar story to tell about going cold turkey on React, you should share it with Richard:

If you or your company has also transitioned away from React and into a more web-native, HTML-first approach, please tag me on Mastodon or Threads. We’d love to share further case studies of these modern, dare I say post-React, approaches.

Tagged with

First Experiments with View Transitions for Multi-page Apps

Some great ideas for view transitionts in here! Also:

If you look at any of the examples on a browser that does not support them, the pages still function just fine. The transitions are an extra that’s layered on top if and when your browser supports them. Another concrete example of progressive enhancement in practice.

Tagged with

Building a Frontend Framework; Reactivity and Composability With Zero Dependencies

The thinking behind the minimal JavaScript framework, Strawberry:

Even without specialized syntax, you can do a lot of what the usual frontend framework does—with similar conciseness—just by using Proxy and WebComponents.

Tagged with

12 Days of Web

All twelve are out, and all twelve are excellent deep dives into exciting web technologies landing in browsers now.

Tagged with

Push and ye shall receive | CSS-Tricks

Imagine a PWA podcast app that works offline and silently receives and caches new podcasts. Sweet. Now we need a permissions model that allows for silent notifications.

Tagged with

Previously on this day

11 years ago I wrote America

Three cities in two weeks.

15 years ago I wrote The Chalkboard of the Fourth Wall

Life? Don’t talk to this anthropomorphised inanimate object about life.

23 years ago I wrote The Mirror Project

If you’re a regular visitor here, then you’ll probably have noticed something new on the journal page - a random picture from The Mirror Project.