Undesired behaviour of FileSystem.Current.AppDataDirectory

[beeradmoore]

Description

When you use FileSystem.Current.AppDataDirectory it outputs a location that according to the documentation is

...the app's top-level directory for any files that aren't user data files. These files are backed up with the operating system syncing framework.

But the output of this on different platforms leads to confusing results.

OS	AppDataDirectory
iOS (simulator)	/Users/bradmoore/Library/Developer/CoreSimulator/Devices/7195125F-89A0-40B7-A8DB-1B343B2AF596/data/Containers/Data/Application/B6A225B4-55DE-447C-A407-6CFA3D118553/Library/
macOS	/Users/beeradmoore/Library/
Android	/data/user/0/com.beeradmoore.myAppName/files/
Windows	C:\Users\beeradmoore\AppData\Local\Packages\52ed336e-9df8-43e1-9c04-74392cd48f3d-218743784238_fids9vfx8fwe\LocalState\

I believe that using AppDataDirectory should give a directory specific to your application. However on macOS it drops you into the root folder of where many applications place files. RIP my ~/Library/ folder which is now a mess on account of not even being able to debug basic strings anymore.

I would propose that for macOS PlatformAppDataDirectory created a folder with application name in either ~/User/Library/<application_name>/ or ~/Library/Application Support/<application_name>/ to give consistent behaviour across all platforms (application_name could also be bundle_id)

Additionally I don't know if these files (possibly those Windows) are backed up by the OS to any cloud.

Steps to Reproduce

Create a MAUI app and run this on different platforms.

System.Diagnostics.Debug.WriteLine(FileSystem.Current.AppDataDirectory");

Version with bug

6.0 (current)

Last version that worked well

Unknown/Other

Affected platforms

macOS

Affected platform versions

macOS 12.4

Did you find any workaround?

Custom handle file paths when building MAUI app for macOS.

Relevant log output

No response

[beeradmoore]

An update on this. If you create a file Platforms\MacCatalyst\Entitlements.plist with the contents,

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
</dict>
</plist>

then FileSystem.Current.AppDataDirectory will actually be /Users/beeradmoore/Library/Containers/<bundle_id>/Data/Library which is more ideal.

This is due to the app not running in a sandbox by default. As far as I am aware macOS apps published to the AppStore need to have sandbox mode enabled (although distributing with the AppStore isn't the only way to release apps)

Additionally with Entitlements.plist existing does not behave correctly in debug mode as the codesign does not do its thing with entitlements when building for debug, only release.

I am unsure what the correct course of action should be. I don't think people should be forced to run as a sandbox by default but there should be more clear as its very easy to kill your computer (eg. your app might have a clean up mode that deletes everything in FileSystem.Current.AppDataDirectory).

Also unsure if apps have any business adding data in to the Containers directory if they are not sandboxed. If that is ok then on macOS if not in a sandbox this call should return

if (sandboxed)
{
    var appDataDirectory = Path.Combine(FileSystemUtils.GetDirectory(NSSearchPathDirectory.LibraryDirectory), "Containers", "<bundle_id>", "Data", "Library");
    if (Directory.Exists(appDataDirectory) == false)
    {
        Directory.CreateDirectory(appDataDirectory);
    }
    return appDataDirectory;
}
else
{
    return FileSystemUtils.GetDirectory(NSSearchPathDirectory.LibraryDirectory);
}

so then at least there is consistent and not dangerous path.

[Axemasta]

@beeradmoore thanks for adding the info here, it's a good explanation of this behaviour.

I have noticed the same behaviour with my Maui Mac Catalyst app since I've added a SQLite database and was looking for the file location so I could open it up. The way things currently operate I don't think is feasible and it is absolutely opening Maui developers up to utter catastrophe. I've worked on Xamarin apps that recursivly deletes app sandbox directories, the damage from an XF to Maui migration could be catastrophic...

With regards to sandboxing by default, this is absolutely a startup template change Maui should introduce. The File > New > macOS route on Xcode enables sandboxing by default:

This would also make the platform experiences consistent because of the big 4 platforms (ios, android, mac, windows), mac is the only platform NOT to run in a sandbox by default.

Pros:

• More consistent platform experience
• Developers less likely to nuke their own macs ~/Library folder
• Consistent with the native macOS developer experience

Cons:

• ????.... Developers have to read some docs? (maybe thats a con?)

[beeradmoore]

Thanks for that. Going to remember to make that change for my own MAUI apps.

Another possible con - from memory having an entitlements file means you need a developer certificate to deploy iOS app to the simulator. Is a developer cert required to run macOS apps?

[Axemasta]

I'm not sure about the requirement for an apple developer account, I've had an active developer account on my mac for years so I've never come across the issue unfortunately.

I do view it as just a barrier to entry for the platform and as long as it aligns with the native tooling (ie xcode), then I personally don't think its much of a hit. The microsoft docs for instance could call this out "you must have an apple developer account to run mac catalyst in sandbox, turn this setting to false if you don't have one..."

[beeradmoore]

Same. Having a wildcard provisioning profile has saved me a bunch of time when playing with prototypes in the past.

And I agree 100%, if it's the norm for native development then it should be fine to be the norm here. So long a docs (or even errors generated in the IDE) help put people on the right path.

[mib71]

This is very frustrating on Windows as well

[Zhanglirong-Winnie]

Verified this issue with Visual Studio Enterprise 17.9.0 Preview 1.1 and VSMac 17.6.7.417. Can repro this issue.