I’ve just upgraded to Catalina. I knew I might have a few problems but every time I try to debug my program I’m asked to grant it access to my documents folder.
Every time???!!!
Have I missed something and there is a way to stop this.
It seems to add the debug app to the Security and Privacy system preference but remove it again when the debug session ends. You don’t seem to be able to add / remove entries on this list manually.
Any advice would be welcome.
Jack
Do you sign your app when debugging?
To get your app into Security and Privacy you need to keep a built version of the app on the disk.
No I don’t sign … to be truthful not sure how I’d do that. I don’t write commercially.
There is a running version of the app on disk, but the debugging version has a different name … myApp.debug.app.
You will need to code sign and notarize to deliver a public build. I believe for the “app on disk” workaround, it needs to be a code signed and notarized version that you’ve run at least once prior to the debug build.
As far as how to do it, Sam’s AppWrapper is pretty much the standard recommendation. I love it, I use it, and Sam is on top of making sure it still works when Apple is feeling bored with their rules. You can find out more about AppWrapper here. You will also need an active Apple Developer account ($99/yr)
There are lots of little caveats and costs to complain about, I’m just trying to provide you with the information you need to implement code signing.
This is ridiculous. I can accept that notarization and signing might reasonably be required for distribution on the MAS, but for debugging on one’s own machine? There must be a better way.
Alternatively, the app could be refactored to respect Apple’s new privacy rules. This warning only appears if you try to access SpecialFolder.Documents without permission from the user. The Apple approved method of acquiring a FolderItem is through asking the user with an Open or Save dialog.
My apologies if I’m not understanding the problem completely, but I am tinkering with some Desktop apps on Catalina (using 2019r1.1 thru 2019r3.1) that don’t yet have any signed or notarized builds installed locally and I can run and debug new (and old) projects without warnings or issues.
@Tim Parnell 's advice, as well as from others like @Jürg Otter are important of course (this is also good to know), but I haven’t got to that point yet with many of my projects. But I can still write new code and run it in debug mode.
Could this just be some sort of permission issue when executing the debug app within the Documents folder?
Do you have your Desktop & Documents folders linked to your iCloud Drive? Could that have anything to do with it?
Note: I store my Xojo projects in a folder off my Home location on Catalina, i.e., /Users/scott/Projects/...
I also have an Apple Dev account and licensed copies of AppWrapper. But I haven’t run into anything on Catalina to force me to use them yet (none of my projects are finished yet). I’m prepared for when I am finished (if I ever do), but haven’t needed to yet.
I hope that helps.
I don’t own a certificate and don’t do any kind of code signing for my apps and I’ve never seen the problem of Catalina asking me for permissions when debugging. @Tim Parnell made the correct observation in my case. I don’t ever try to access the Documents folder. My databases are stored outside the traditional documents folder. I realize my case is likely an outlier, but it verifies (for me) why I am not having a problem.
Accessing the Documents folder, Downloads folder, Desktop Folder, connected volumes all require permission given by the user.
Permission can be granted by either the annoying "Allow/Deny’ dialog or via a Open/Save Panel, or the System Preferences.
The problem lies in that how the macOS remembers which apps have permission is NOT published (to my knowledge) there are many assumptions, mine is that unless the app is signed it uses the app’s UUID (not bundle identifier) and for each build the UUID is different. Once the application is code signed, it then uses something else (IMHO, then it uses the bundle identifier).
You should also fill in the required privacy strings for these places.
App Wrapper can help you with both of these.
Most importantly, the one reason which I believe drives this change more than anything… You need to have an active Apple developer account, which costs $99 USD for 5 years, or if you want to release software on the internet it’s now $99 USD every year. As Tesco’s would say, every little helps…
Thank you @Sam Rowlands and @Tim Parnell, this is all great to know.
I do store my app SQLite db’s in SpecialFolder.ApplicationData.Child(...), but beyond that, I don’t use the Documents or Desktop folder on Mac or Windows. This is mostly out of habit, because I’ve found these folders usually end up becoming a dumping ground for junk by other apps like MS Office.
For any personal documents, I always make a “Files” folder off the root of my Home folder, on both Mac & Windows, just like I do for projects.
This is a good reminder that I should be testing access to those folders though, when running my apps that access external files.
I guess this could potentially explain the original poster’s problem…
OK, thanks; I have no problem with accessing Documents, Desktop, etc. via Open/Save dialogs. So ApplicationData can be used for prefs etc without a permissions nightmare?
Yes. SpecialFolder.ApplicationData and SpecialFolder.Temporary are accessible without the permissions warning.
Before Sandboxing; many a Mac app would create a subfolder in the users “Documents” folder to write data there. This IMHO is the best scenario as it means that the user knows where their data is stored.
The App Sandbox walled off the “Documents” folder by default, it was only accessible via an open/save dialog (and persistent access required the use of Security-Scoped Bodgemarks).
I petitioned Apple to add an entitlement allow each application unrestricted access to a single folder (of the application’s name) within the Documents folder, such as “~/Document/App Wrapper/”. Unfortunately Apple’s security team, decided against this.
A couple of years ago, an application of mine was rejected from the App Store because it saved user data into the Application Support folder. The reviewer felt that this was the wrong place. I managed to get the rejected overruled because it was a bug fix release for the app to work with Apple’s latest OS. I tried again with Apple to get a Sandbox entitlement that would allow unrestricted access to a specific folder in the users “Documents” folder. Once again, my request was closed as by Design.
The statement that Apple have given on how we’re supposed to do this, is to produce a open/save dialog on first launch asking the user Where they want their data saved, store a Security-Scoped Bodgemark and proceed. This raises more questions than it answers, is a messy fail prone solution. OS updates can and sometimes and do break SSBs, leaving your application with no access and what’s worse, when they fail, your application has no idea where that location was or even what it was called (again by design).
My current line of thinking is as follows.
Of course if your application uses Open & Save dialogs to load and save user data, none of this is necessary.
Be wary of the temporary folder under Catalina, when it first shipped I had a handful of customers who for some reason had a locked Temporary folder. I haven’t seen this issue recently, but I’ve also switched most of my functions to using either the Caches folder or in the case of atomic saving, they use the recommended Apple API (with a slight modification to clean up after it).
Thank you again Sam, I really appreciate your insight and diligence for the community.
Having worked the past 20+ years as a web developer, programming for Desktop environments still presents surprises to me. You and Tim and others are a true wealth of information.
Sounds like I’m good to go, so far 
Sorry forgot to answer this one: Technically you are supposed to use NSUserDefaults (either via declares or the MBS plugin) to store and retrieve “Preferences”. Never directly access the Preferences folder, as in the past, Apple have changed things which broke applications that do (as hey, we used to do this ourselves back in the ole days).
There is an old Feedback request in Xojo (wrong puter, can’t check atm) for providing native support for accessing “Preferences” via NSUserDefaults. If you manage your own preferences (which has some advantages), the best place is indeed the Application Support folder.