It’s still too difficult to link to content inside many of Apple’s own macOS apps.
That’s where the idea of omni-links comes in — persistent, context-friendly links to digital items across apps and documents. Omni-links let you move fluidly between related content, no matter where it’s stored. They’re a cornerstone of what David calls “contextual computing.”
Unfortunately, macOS apps like Messages, Podcasts, and Music still make it difficult — or impossible — to obtain links to specific content. Notes doesn’t offer a proper “Copy Link” UI, though Hookmark works around this limitation by using the note’s date-created information (which persists across macOS and iOS via icloud). Podcasts and Music bury linking under awkward UI paths, and their objects aren’t scriptable. Messages offers no public API for message IDs at all.
This issue is the focus of the Manifesto for Ubiquitous Linking, co-signed by David Sparks and others. It calls on developers — Apple included — to expose simple ways to copy links to their apps’ digital content.
I recently published a Substack article titled “Apple’s macOS Apps Are the Weak Link: Ubiquitous linking is needed, and possible.” It unpacks this situation and offers a hopeful vision for what linking could look like if Apple brought its own apps in line with the capabilities macOS already supports.
I am curious how others in this community are working around these limitations. Have you found any good strategies for managing contextual workflows despite Apple’s omissions? How can we influence Apple and other app developers to make their apps link-friendly (i.e., to follow the recommendations of the Manifesto for Ubiquitous Linking)?
Given Apple’s provision of “URL schemes” for apps, it seems like they have no excuse.
I agree this is a very powerful and needed capability. I should be able to have a calendar appointment with a link to an email or a reminder with a link to a message, and so on.
Most businesses use Microsoft or Google software which has linking features in many of their programs. Apple’s apps are free and mainly used by individuals, families, and small groups. And I don’t think Apple has any reason to invest a lot of time and effort creating features for a very small percentage of users. Especially since it would not result in any additional revenue.
OTOH Apple is investing heavily in “Apple Intelligence” which will rely on app intents to allow their “new Siri”, Spotlight, and widgets, etc. to perform all kinds of helpful tricks. I suspect that may result in new actions to allow more programs to work together. So fingers crossed.
Google is actually even worse for linking in some respects. Here’s a quote from an upcoming paper of mine (submitted for Human’25 ACM Hypertext conference this sept:
Some prominent web apps, such as Google Docs, Notion, and Discourse, do not allow users to paste app links into their documents. (In contrast, in Apple’s iCloud.com web apps, such as Notes, one can paste app links.) Nevertheless, it is possible to overcome the above hurdle by creating a universal link for the target resource. A universal link is a web (https://) link, so it can be pasted in any web app that supports web links, including Google Docs, Notion, and Discourse, for example. Universal links require a server. For privacy, a universal link server must not (and hookmark.net does not) store any universal link it processes. All that happens is that macOS or iOS sends this link to the registered app; in our case to Hookmark (which previously registered itself with the macOS instance to handle https://hookmark.net). The Hookmark app then converts the universal link to an app link, and Hookmark subsequently asks the macOS instance to open the target resource. In short, universal links are converted locally to regular app links and opened by the HR-CIR software.
I can see how that could be true for someone working in an all Apple environment. I never worked in an all Apple shop, or one that could have used iCloud.
While I understand this sentiment, it doesn’t hold up on mobile as Apple continues to not allow users to set a third-party app as the default app in many categories. If they actually supported that, then this reasoning would make sense. For me, it is the conflict between the limitations of Apples more basic functionality and the frustration of using an app that the system doesn’t recognize as the default app for that category. In the end, the default app usually wins out, which means I don’t get those advanced features I would like.