Why did my SpecialFolder.ApplicationData path change

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.

I think that structure is used when the application is sand boxed which is probably a side effect of completing some of the build settings.

If you don’t want your application to be sand boxed (or you don’t understand the implications) I suggest you revert the values.

The setting you’re looking for:

2 Likes

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.

That is correct.

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.

1 Like

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.

Screenshot

FolderItem.Open will open the folder in Finder showing the contents.

1 Like

If I have an Export, won’t they still have to grant access to use the folder to where it’s saved?

Yes, but you do that with the normal process of a Save Dialog, which is Apple approved (and what users are going to expect).

I’m not familiar with what that process is anymore.

You also need to use SSBs because accessing files is dangerous. It sounds like you are at the start of your journey with the AppStore.

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.

Javier’s post is the last part you need to do. For now you need to learn the differences between a normal app and a sandboxes one.

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?

No, but you need an entitlement for it. In AppWrapper it’s the Network Access section.

1 Like

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?

When making requests (URLConnection) you are the client. Invert those checkboxes, as you only need incoming permission if your app is a server.

1 Like