Last month, Apple added a note about macOS pasteboard privacy to the AppKit release notes for developers:
Prepare your app for an upcoming feature in macOS that alerts a person using a device when your app programmatically reads the general pasteboard. The system shows the alert only if the pasteboard access wasn’t a result of someone’s input on a UI element that the system considers paste-related. This behavior is similar to howUIPasteboardbehaves in iOS. Newdetectmethods inNSPasteboardandNSPasteboardItemmake it possible for an app to examine the kinds of data on the pasteboard without actually reading them and showing the alert.NSPasteboardalso adds anaccessBehaviorproperty to determine if programmatic pasteboard access is always allowed, never allowed, or if it prompts an alert requesting permission. You can adopt these APIs ahead of the change, and set a user default to test the new behavior on your Mac. To do so, launch Terminal and enter the commanddefaults write <your_app_bundle_id> EnablePasteboardPrivacyDeveloperPreview -bool yesto enable the behavior for your app.
It turns out that when the new hidden preference is set, my own app Link Unshortener triggers an alert on launch.
Why does this happen? When you open a URL in Link Unshortener, a new window opens with the URL automatically displayed in the text entry field, ready to unshorten. When you launch the app manually or select the "New Window" command, on the other hand, there's initially no URL to unshorten, so Link Unshortener helpfully looks for a URL in the pasteboard and, if one is found, automatically displays it in the text entry field, which would otherwise be empty. This feature makes it easy to copy a URL from another app and use it in Link Unshortener.
If Apple follows habit, then macOS 16 will be announced and previewed next month at WWDC 2025. I expect the California-themed name to be macOS Alcatraz. Presumably, the new pasteboard alert will appear by default in macOS 16, presenting a number of problems for users and developers. First, the alert has no option to always allow paste. Second, the alert has no explanation of why the app is trying to access the pasteboard. Third, and most important, I don't want the first launch experience of my app to be a permissions request.
Thus, I'm simply removing the feature from Link Unshortener that autofills a URL from the pasteboard. It's not an essential feature for the app, just a minor quality of life improvement. I'm making the app a little worse to avoid the much worse permission prompt.
A new section of System Settings allows users to manage the pasteboard permissions of apps that have requested access. However, users have to find the new section in System Settings for themselves, or an app that needs permissions has to open System Settings for users, because the visually and functionally meager system alert won't do it.
Perhaps at WWDC, Apple will announce a new Info.plist key for apps to specify a reason for pasteboard access to appear in the new alert. Other such keys already exist, such as those specifying the reason for location and microphone access. As far as I'm aware, though, no new API exists for that yet.
Regardless of the ultimate design of the alert, its wording and options, my biggest problem with the alert is its very existence. That's why I'm removing a feature from my app. I'm not going to argue in this blog post about whether the new macOS privacy protection is necessary or good; I'll merely note that there are almost always tradeoffs between security and usability. One of the tradeoffs here is that my app is becoming a little less usable. Link Unshortener's use of the pasteboard was never malicious. It was meant to help users, not harm them. And the feature has been in the app since the beginning, five years ago. (I just realized that the 5th anniversary of Link Unshortener was last month!) Indeed it was the very last git commit before releasing version 1.0 of Link Unshortener: "When opening a blank window, check for a URL on the pasteboard."
It's likely that some other Mac apps will suffer worse fates than mine, apps that rely on pasteboard access as an essential feature. I actually ran defaults write -globalDomain EnablePasteboardPrivacyDeveloperPreview -bool yes to enable the hidden preference in all apps, but I had to disable it soon thereafter, because I ran into too many annoying problems. For example, the permissions alert appeared when I pasted a URL into the Google Chrome address bar. In Safari, cut and paste were very wonky too: sometimes I saw the alert, sometimes my actions just failed silently. Begun, the clipboard war has.