I’ve been using
appSupportFolder = SpecialFolder.ApplicationData.Child(“appName”)
to save my SQL database. And it’s been saving the files to:
/Users/Chuckbo/Library/Application Support/appName/
But when I ran the app this morning, it changed. Now my ApplicationData folder is:
/Users/Chuckbo/Library/Containers/com.clhwares.myapp/Data/Librarian/Application Support/appName.
The only thing last I’ve changed since I last ran the app is I filled in the macOS Build settings.
Is there some advantage to this more-buried folder? I’m leaning to saving the database in Documents/appName since I want users to be able to access it and share it with other users. It wasn’t so hard to find when it was directly under ApplicationData, but now it’s not so easy. Or tell me if I’ve confused something somewhere — and the path really shouldn’t be this deep.
Thank you guys. You both are correct. I changed the Sandboxing setting last night.
I read that to submit the app to the App Store, Sandboxing has to be enabled. And I also saw that step in Javier Menendez’s article on publishing to the MacOS store.
It convinces me that I want to move the database location to Documents.
You will still get a containerized Documents unless you ask the user for a save location. That’s what Sandboxing does. Your application will be restricted to its own little sandbox to play in. You lose direct access to the user’s system without explicit permissions (Save / Open Dialogs or Full Disk Access).
In my opinion, guessing without knowing your app, SpecialFolder.ApplicationData.Child("My App") is the correct location, Sandboxed or not.
Thanks for the advice.
Sounds like I’ll have to add some information in the documentation that will show users that full path so they can find the files they create. If someone’s motivated enough to create content for others, then they’ll find those files. And then no one else has to go through the hassle of the Full Disk Access.
Why would you not have a Save or Export feature in the app?
You could also do what BBEdit does, have a menu or button that shows the folder, though to be honest I do not know if that is allowed in the App Store. You may wish to research that.
You don’t need to deal with Security Scoped Bodgemarks unless you’re trying to retain access to the out-of-sandbox location between launches, which is something I’m glad is very difficult to do.
You’re right; I’m at the very start. I applied for the Developer’s license last Thursday. I’m relying on Javier’s post from last March as my flowchart.
And I hope it’s going to be simple enough for an old programmer like me to wade through.
What are the relevant differences? I didn’t see much in the documentation - not like you’re talking about but maybe I’m not searching in the right place.
Maybe I understand now the difference for where my database file will be stored, at least I understand the two paths. That’s the only file that I interact with. What else do I need to deal with regarding sandboxing?
AppStore apps are mostly suited to document based apps. AppleScripts are not permitted as well as shell calls or FullDisk Access. I asked ChatGPT and it’s answer seems reasonable:
Quick “developer smell test”
If the feature requires any of the following, assume “not possible or not App Store-viable” until proven otherwise:
touching files without a user picker grant,
controlling other apps,
running external processes/tools,
installing helpers/agents,
deep hardware/system hooks,
or executing code not shipped inside your signed bundle
No, I might not be doing any of those.
And the only doc I’m interacting with is the database — where I’m storing data that I’m entering and then reporting it.
But I am calling an API from a public site and getting data from it. Is that going to be considered an external process?
I enabled the Incoming Connections last night — seemed to make sense to me since I’m getting data.
Or should I enable Outgoing Connections since I initiating the connection?