Bug 194593 - Add support for Web Share Target API
Summary: Add support for Web Share Target API
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: Safari 12
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Keywords: InRadar
Depends on:
Reported: 2019-02-13 08:38 PST by Thomas Steiner
Modified: 2020-07-22 19:19 PDT (History)
14 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Steiner 2019-02-13 08:38:30 PST
Following the implementation of the Web Share API (https://bugs.webkit.org/show_bug.cgi?id=171100), the next logical step could be the implementation of the Web Share Target API (https://wicg.github.io/web-share-target/), which in fact is an extension (https://wicg.github.io/web-share-target/#extension-to-the-web-app-manifest) of Web App Manifest (https://www.w3.org/TR/appmanifest/). 

Companies like Twitter use this already (https://mobile.twitter.com/manifest.json):

"share_target": {
	"action": "compose/tweet",
	"params": {
		"title": "title",
		"text": "text",
		"url": "url"
Comment 1 Radar WebKit Bug Importer 2019-02-14 11:16:59 PST
Comment 2 Filip Bech-Larsen 2019-03-11 12:38:40 PDT
I would love to see this work so webapps can be opened with content like real apps. 

The squoosh.app app uses webshare target-api on Android and it would be so much easier to add an image from an email (or somewhere else), without having to add to the gallery first.

The first step of cause is the text-only version which is better than nothing, but the real deal would be the full formdata version so anything* could be shared.
Comment 3 Mike Watson 2019-03-19 06:24:35 PDT
Adding support for the `Share Target API` will be incredibly useful capability.  

Our app, https://sprout.io, has the need to quickly bookmark and create collections of learning resources from mobile devices.

This is easily done on desktop with extensions, but the `Share Target API` is needed to supported this popular use case on mobile.

Adding support for the `Share Target API` will help democratize access to this share capability for apps of all sizes (even those who lack the budget to develop native apps/share extensions across all platforms).
Comment 4 aarontgrogg 2019-04-10 04:26:40 PDT
Yes, please!  Standardization is huge for developers, but more importantly for users to feel comfortable!
Comment 5 Ernst 2019-04-15 01:43:41 PDT
+1 It will be fantastic to have this.
Comment 6 jonhargett 2019-04-26 20:27:18 PDT
I have an existing Android and iOS app that is an ePub reader. It currently works by "sharing" an epub file with my app and then it is imported in to the app. Would be helpful to make it as a PWA instead. If this feature is implemented with the file support, could import the file in and then store the contents in storage for viewing later.
Comment 7 overclockedllama 2019-12-21 04:38:52 PST
Is there any update on the development of this feature. It would make iOS PWAs an actually viable option for many more use cases in the future.
Comment 8 Karel Vanden Bussche 2020-06-02 09:58:04 PDT
This would indeed be perfect for all web applications that ingest data. This would increase the UX value of a whole segment of apps. This spec has been some months old. It saddens me that Apple keeps pushing the brakes for PWA support.
Comment 9 Jerome Quah 2020-07-22 19:19:46 PDT
(In reply to Karel Vanden Bussche from comment #8)
> It saddens me that Apple keeps pushing the brakes for PWA support.

Other than the fact that Apple, at launch of the iPhone, pushed for Web apps over native apps, the complete opposite of pushing the brakes I'd imagine; (Archive of their 2007 web app directory: https://web.archive.org/web/20071012025941/apple.com/webapps)

You should not be expecting Apple to be rushing to implement an API that is not on the W3C standards track. No one except Google has shipped support for the Web Share Target API. Mozilla's Firefox team still has this on their to-do list. (https://github.com/mozilla-mobile/fenix/issues/5783)

It is a feature proposed by Google, hence you'll find the API for it in Chrome, Opera, and Edge; the major browsers that are all based on Chromium.

Important to note that the WICG draft for this linked by Thomas states explicitly that it is a 
> draft of a potential specification.
and that it has 
> no official standing of any kind and does not represent the support or consensus of any standards organization.

Though I understand why he didn't specify the document's status; it would've been the opposite of trying to sell an idea.

That being said, I do hope this is being considered for development as it does more good than harm for the web as a whole, just make sure to have reasonable expectations of companies and developers.