Quinn, Since you've written this answer, Big Sur has come out and it SEEMS to further complicate the situation: we have clients (on our non-sandboxed app) where they open a file using the system file open panel, and that works -- UNTIL sometimes they get a Big Sur update and then our app no longer has the same access permissions it had prior to the update. We know this is happening because we ultimately have to have users grant Full Disk Access permissions, just so they aren't continually hassled by this issue. Do you have any clarifications about Big Sur's handling of access for non-sandboxed app? On a related note, we want to develop and test for situations where this problem comes up, but we don't know how to revoke our app's access to any files/folders the user has ever opened. Removing/unchecking the entry in Big Sur's "Files and Folders" panel in the Privacy panel doesn't seem to reset those permissions. Thanks! Stephen

Quinn, so YOU WERE CORRECT -- I needed to add the SERVICE. DTS must have missed that, too. I will also email you the ticket number. HOWEVER, I'm suspect that "Accessibility" is perhaps NOT the right service, because resetting Accessibility did NOT reset the Files and Folders settings for the app or bundle ID. We are trying to reset this tcc data: if the user UNCHECKS an allowed folder for an application (say "Documents"), subsequent attempts to use POSIX open() on a file inside that folder will NO LONGER present the system alert: " would like to access files in your Documents folder" (OK / Don't Allow) This has become a problem, because unlike the first access attempt which DOES ask that question, open() gets an exception with POSIX error 1 "unable to open that document -- operation not permitted". So I'm sure you're thinking: why would the user actually uncheck the Documents folder access permission? The answer is that they DON'T -- this appears to be some sort of bug in Big Sur, where an Apple pushed Big Sur update somehow disrupts the already-approved permission of the Documents folder for our application. So we're trying to fix that so MacOS will just re-ask for access as if it never knew anything about the Application's previous permissions. ...which is why we're trying to reset that information in the tcc. Stephen

Quinn, You were exactly correct (as usual). SystemPolicyDocumentsFolder was the proper service name for tccutil. And -- you're also wise to caution us against continual use of tccutil. But here's what we're facing (mentioned here in case other devs stumble onto this issue): With approximately .5% of our users, we've observed a problem that mostly seems to her with Big Sur, where after the user has granted access, usually by explicitly opening a file (or several() inside a folder that is inside the Documents folder, at some point, usually after a MacOS system or security update, the tcc database gets messed up, and the app's previous permissions are "forgotten". As best we can tell, the Documents checkbox in Files and Folders is STILL CHECKED, but our app can no longer access/open the file we desire. And the user is no longer prompted by the system to grant access. This is in an app that does NOT adopt sandboxing. I'm going to try the obvious: explicitly present the location of our supporting document template to the user using NSOpenPanel, and see if that will restore access. Normally, the user doesn't ever directly select this file or its enclosing folder. But if that works, great. Unfortunately, despite discussing this issue with DTS for 10 months, there's been no acknowledgment that there is any issue / defect in MacOS that could cause what I'm seeing. So it MIGHT be pilot error, but hard to see how.

Quinn, this is on MacOS -- 10.15 Catalina and above.

Maybe this is a question for me to shoot up to DTS?

Quinn, As of February 2023, this code DOES launch Outlook, but will NOT attach a document to the Outlook-created email: ` NSString* msgText = @"This is text for the body of the email"; NSMutableAttributedString *maStr = [[NSMutableAttributedString alloc] initWithString:msgText attributes:@{ } ]; NSSharingService* mailShare = [NSSharingService sharingServiceNamed:NSSharingServiceNameComposeEmail]; NSArray* shareItems = @[maStr, fileToSendURL]; [mailShare performWithItems:shareItems];`