Sharing functionalities in iOS and Windows

Sharing data among apps is a common task in modern operating system. Both iOS and Windows Runtime provides central means of transmitting data from one app to another beyond the clipboard. In this entry, I will look at the sharing functionalities in both systems.

Icons in the hero image are drawn by me looking at the icons. They are not exact reproduction of the icons in Windows and iOS.

Quick points

In iOS, the ‘Copy to’ things are file associations, not Share Extensions.
In iOS, Share Extensions only show modal UI above the current app, whereas the file associations will switch app.
In iOS, the phrasing of file association tasks in Activity Sheet has been revised and is clearer than before.
I think an improvement for iOS is to list Share Extensions and file associations separately.
In Windows, sharing always initiates a hosted UI. The hosted UI was light dismissable can must complete the sharing within the hosted UI. Now it is a non light-dismissable modal dialog (after the target app is chosen) and can invoke the main UI to finish sharing.
In Windows, file associations have nothing to do with sharing, and sharing has nothing to do with file associations.

iOS

I always wondered what was the difference between choosing an app in the Activity Sheet in iOS and choosing ‘Copy to’ (formerly known as ‘Open in’; in French, they are ‘Copier vers’ or ‘Ouvrir dans’), as shown in the screenshot. From a user’s perspective, I observed a few outcomes of choosing different options, and the conclusion is the following:

If you choose an app, a modal dialog of the share target is shown above the current app. Typically, choosing social media (e.g., Weibo, Twitter and Facebook) will give you a pop-up with the current app dimmed, in which you can modify the content before posting it. However, for some other apps, noticeably messaging apps including Messages and WeChat, that you are not switched out of the current app sometimes can be hard to realize, because they show a full-screen modal window that completely covers the current app.

If you choose ‘Copy to’ an app, you will switch to the target app. It turns out that, though shown together with Share Extensions, these are not the same as the above Share Extensions. The first thing to notice is that these options appear only when there is a ‘file’ in context. This makes a clear distinction between the two. However, it could also be the case that there is a guideline set by Apple. Namely, there could be two subtypes of Share Extensions. However, the distinction between the two is still unintuitive, at this moment.

Several natural questions:

Why did the wording change from ‘Open in’ to ‘Copy to’?
Why do some apps have both itself and ‘Copy to’?
What is the underlying difference between tasks with and without ‘Copy to’?

My speculation for the first question is that ‘Open in’ might give the impression that the target app might be able to share its modification with the current app, which is not the case. Phrasing it as ‘Copy to’ makes the thing clear, as whatever is done in the target app is done to the copy that app receives.

Let’s look up the documentation (stop just being a user) for the other two questions. According to Apple, Share Extensions cover both sending data to other people and sending data to other apps (we will return to this later). A comment to Raymond’s blog entry on history of Windows 8 Charms sounds like there is a distinction between sharing data to people and sharing data to apps. The documentation confirms that there is no such distinction. I suspect Alex Cohn thought the two kinds of tasks shown in that row of Activity Sheet are discriminated by the target (person or app).

Whether an app is shown as ‘Copy to’ is decided by its file association registration. That means an app is eligible to be shown as a ‘Copy to’ activity if the current app provides a file and the target app declares its capability to handle that type of file.

In short, options without ‘Copy to’ are Share Extensions, whereas options with ‘Copy to’ (not counting those prepends ‘Copy to’ to its Share task name) are file associations.

The problem here is that an app can of course be a share target as well as a file handler. Outlook is capable of handling URLs and attachments in Share, and can handle files in the sense of file associations. The result is that when you are sharing a PDF on the Web, Outlook appears twice, once as ‘Outlook’ and once as ‘Copy to Outlook’, in Activity Sheet, creating confusion: Choosing either option allows you to compose a new e-mail with the PDF attached; however, choosing ‘Outlook’ will not switch to Outlook while choosing ‘Copy to Outlook’ switches you to Outlook.

App developer could avoid the confusion by using predicates to disable the app when the file handler can select the app (you cannot programmatically hide the file handler, unless you cease to handle that file type). However, that is not a full solution. Firstly, the two options might have different display preference, and some users don’t even know they can choose which tasks to show. Secondly, take message composing as an example: The distinction between whether or not the user is switched to another app isn’t clearly conveyed bt the phrase ‘Copy to’. Finally, it is good to have the option whether or not to switch to another app, depending on the weight of the user’s task in question (e.g., composing a long e-mail v.s. composing an SMS).

I think a compromise is to list the two kinds of operations separately: Activity Sheet could have three rows, Share Extensions, file associations and Actions.

Windows

Windows Runtime provides a central means of transmitting data among Windows Runtime apps since Windows 8. Originally, this is invoked by the Share charm. Windows Phone also has the corresponding API. Windows 10 no longer has the Charms, but the sharing functionality is still preserved. Until Windows 10 version 1703 (Creators Update), the sharing was still done in the Charm UI, which was light dismissable. Since that version, sharing UI has been updated. Now when an app is ready to share data, a light-dismissable pop-up shows up for the user to choose the share target. When an app is chosen, a modal (non light-dismissable) dialog is displayed above the current app. The modal dialog is supposed to continuate the previous hosted-style UI in the Charms, but it is also possible to open the target app at the developer’s discretion.

In Windows Share UI, only apps that manifest themselves capable of handling the shared data are shown (in addition to ‘Quick Link’ shortcuts, each of which can be inserted by an app only when it was chosen as the target and reported a successful operation). File associations do not participate in the procedure of selection. Developers who wish to handle shared files in Share must also declare their apps as capable of handling such shared data.

Anecdotes now. According to the blog entry by Raymond Chen that I mentioned earlier, Windows originally was about to differentiate the concept of sharing data to people (e.g., messaging and social networking) and sharing data to apps (e.g., uploading data to cloud storage). However, the feedback from intern developers indicated that such distinction is vague. I can imagine such distinction isn’t really meaningful to the users. Certainly abandoning the idea of such discrimination is a good improvement in UX. This reminds me of the case of the device removal notification icon.