The curious case of ShareLink with plain text strings

I’m currently playing with ShareLink, a lot, for my upcoming app SharePal. And I couldn’t miss this very strange and inconsistent behavior I got with it. Specifically when providing a string as an item.

SharePal

Lighting speed sharing!

Learn more

ShareLink manifesto

ShareLink is an iOS 16+ SwiftUI view that allows to create a Share Button in your app. It packs all the logic of the previously known UIActivityViewController but with a more declarative form like expected for a SwiftUI view.

struct ContentView: View {
    let url = URL(string: "https://blog.thomasdurand.fr/story/2023-09-24-curious-case-of-sharelink/")!

    var body: some View {
        // Share this blog post
        ShareLink(item: url)
    }
}

You can also provide a ViewBuilder closure after the ShareLink, to customize the content of the Share button:

struct ContentView: View {
    let url = URL(string: "https://blog.thomasdurand.fr/story/2023-09-24-curious-case-of-sharelink/")!

    var body: some View {
        // Share this blog post
        ShareLink(item: url) {
            Label("Share this story…", systemImage: "bolt.fill")
        }
        .buttonStyle(.borderedProminent)
        .buttonBorderShape(.capsule)
    }
}

But ShareLink is not that simple

ShareLink can take any Transferable value as an item. But to provide more info to the Activity Sheet, ShareLink comes with three extra parameters: subject, message and preview.

But this is where it start to become confusing:

• message will append the given message to the shared item in apps that supports them, like Messages.
• I’ve never seen subject to do anything anywhere. But according to the doc, it’s for supported apps.
• preview allows you to replace the whole header of the share activity view, providing a custom image and text to be shown. Very handful for custom types, and does nothing on the share payload itself.

The curious case of string sharing

I’ve ran into a pitfall. While I was sharing simple strings, I would expect string actions to be presented, including the “Copy” option.

But at some point during the development, the Copy option disappeared. And it looks like a bug from Apple on that part.

This is what I experienced, passing a simple string as an item:

Simple ShareLink	ShareLink with a subject	ShareLink with a preview

Not only the preview would break the default behavior for sharing my String, but also passing a subject without a preview would break the default preview.

I naturally filled FB13202238.

AirDrop, the rising star?

I’m a huge fan of AirDrop, and I use it whenever I have the chance. And it mostly work great.

But when sharing a piece of text … it opens Files.app, and put the text in a file that is impossible to open by default.

And it’s a behavior I also witnessed with custom files types, exported by the app itself: the file is created in the Files.app, and nothing, not even a popup, allow us to open our custom app instead of the default Files.app.

It’s sad, because it prevent to create better share experiences when using AirDrop for our customers. So I also filled FB13202276.

Shouldn’t everything be an URL?

Share and AirDrop work great for URLs, and URLs are often the way to go for sharing data.

It unlocks App Clip capability, and with a webapp, it offers compatibility for any phone (including Android) to access the shared information.

And with Universal Links, it’s transparent for customers that have your app installed to be redirected to your app.

But it requires a server, a back-end for the storage, and a front-end for the webapp. And unless you use an end-to-end encrypted approach, you’ll have to deal with user data as well.

Using URLs and end-to-end encrypted data is the approach I’ve chosen for Padlok

But for SharePal, even encrypted, I do not want to deal with data on my servers. So I’ll have to stick with the “broken airdrop with text”. Unless Apple fixes my radars 🙃

SharePal

Lighting speed sharing!

Learn more