feedback-assistant
FB17587626: NSPasteboard needs a way to programmatically request full access to the pasteboard
Submission Date
2025-05-13
Status
Open
Area
AppKit
Operating System Version
macOS 15.4
Type
Suggestion
Description
This in regards to: https://developer.apple.com/documentation/updates/appkit#macOS-pasteboard-privacy
Currently, when the developer preview is enabled, it shows an access dialog when my app accesses the pasteboard, but the dialog only lets the user allow one time. My app is fully dependent on being able to read the pasteboard in the background multiple times.
There needs to be a NSPasteboard#requestFullAccessToPasteboard() type method. Similar to EKEventStore#requestFullAccessToEvents().
For reference, my app works by modifying the pasteboard to clear formatting from text: https://apps.apple.com/app/id1611378436
I think limiting access to the pasteboard is a great move, but please don’t make it so hard for apps that need genuine full access to the pasteboard.
Keywords
No response
Prerequisites
- [x] The title follows the format
FB<number>: <title> - [x] I will keep this issue updated with Apple's responses
For what is worth, absent such method which I agree would be very much needed, I went with an alert that either leads the User to the proper Settings pane, instructing to "Allow", or offers to quit the app, as without permanent access it would be useless, and with the default Ask behavior would be the most annoying thing it the world.
Here's my alert:
The URL for the (currently hidden) Settings pane, courtesy of an anonymous comment on Micheal Tsai's excellent blog is:
x-apple.systempreferences:com.apple.preference.security?Privacy_Pasteboard
Apple reply:
Thank you for filing this feedback report. We reviewed your report and determined the behavior you experienced is currently functioning as intended.
The HI design for iOS (which we are following on macOS) states clearly that the dialog itself should NOT include a direct link to the System Settings pane where the "always allow" option exists. The goal is to avoid making it too easy for apps to bypass the feature by getting users to grant "always allow" rights after fatiguing them sufficiently by showing excessive dialogs.
For the same reason, we should introduce API that lets apps simply show a dialog in-process that would grant such "always allow" permissions.
Instead, a proper "onboarding" flow should guide users to the corresponding System Settings pane under Privacy & Security, so users are clearly aware that they are making a privacy-related and permanent change.
That said, with an eye towards streamlining such "onboarding" behavior for e.g. pasteboard managers, we have at existing API to query the current state of the app (NSPasteboard.accessBehavior).
If the issue is resolved, you can close this feedback by selecting “Close Feedback” via the Actions button found above. If we don’t hear from you in the next two weeks, we’ll assume the issue is resolved or not reproducible and will consider this issue closed. After this time, you can create a new Feedback report if the issue remains. Thank you.
This rubs me the wrong way on so many levels:
-
How should developers know that Apple, on this specific issue, is following the Human Interface guideline for iOS on macOS?
-
Telling the User where to go is okay, but providing a direct link is not, because above all we should treat Users as people incapable of making good decisions.
-
But yeah, let's assume instead that people will read a long instructions message, and when they won't, developers will deal with the one-star reviews and burdensome support requests.
-
"For the same reason, we should introduce API that lets apps simply show a dialog in-process that would grant such "always allow" permissions." Yeah, you should, and no moment would have been better than before getting started on this.
I could continue... but I'll just close stating the obvious, that app review is as inconsistent as always, since my ClipBar update passed review with a button that links to Settings.
Bah.
My reply:
Thank you for the clarification. However, I still believe the current approach is flawed — not in intent, but in execution. This isn't about weakening privacy, but about enabling a privacy-respecting, user-consented workflow that works within the constraints you've already set.
You say the goal is to avoid letting apps “fatigue” the user into granting always-on access. That’s completely reasonable — but that’s not what I’m proposing. I’m asking for a clean, official API to initiate the existing consent workflow in a structured, respectful, Apple-sanctioned way. Just like:
-
EKEventStore.requestFullAccessToEvents() -
PHPhotoLibrary.requestAuthorization()
These APIs protect persistent, highly sensitive user data — and yet developers are trusted to initiate the flow via system-branded prompts with clear explanations. Pasteboard access is no more sensitive, and arguably less: it’s transient, user-driven, and not stored permanently.
Without an API, developers are forced to create their own onboarding flows — inconsistent, often unclear, and easily misunderstood. Users are already overwhelmed by the growing number of permissions and manual steps on macOS. The fatigue isn’t just from prompts — it’s from navigating countless variations of custom instructions. That fatigue leads to blind consent, not informed choice.
This also unintentionally punishes legitimate use-cases — like clipboard managers — while doing little to stop determined bad actors. Yes, persistent access is technically blocked, but bad actors can still guide users through enabling it using persuasive or misleading onboarding. In fact, malicious apps are often better at manipulating users than legitimate ones are at explaining things clearly. They optimize for conversion. Responsible developers, meanwhile, are penalized for playing fair — left with poor UX and no system support.
A proper NSPasteboard.requestFullAccess() API wouldn’t reduce security — it would improve transparency, consistency, and user understanding. Apple still controls the flow, the messaging, and the behavior — but developers get a path to do the right thing, and users get a moment to understand what’s happening.
Please reconsider. This is an opportunity to support both privacy and usability.
And of course in macOS 26 Spotlight now has a built-in clipboard manager, which does not ask for permission 🤨
