macOS dotfiles should not go in –/Library/Application Support

I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: https://codeberg.org/dirs/dirs-rs/issues/64. It's very frustrating.

I now use a combination of xdg + known-folders manually:

    [target.'cfg(windows)'.dependencies]
    known-folders = "1.2.0"

    [target.'cfg(not(windows))'.dependencies]
    xdg = "2.5.2"

to get the config directory:

    use anyhow::{Context, Result};

    #[cfg(windows)]
    fn get_config_base_dir() -> Result<PathBuf> {
        use known_folders::{KnownFolder, get_known_folder_path};
        get_known_folder_path(KnownFolder::RoamingAppData).context("unable to get config dir")
    }

    #[cfg(not(windows))]
    fn get_config_base_dir() -> Result<PathBuf> {
        let base_dirs = xdg::BaseDirectories::new().context("unable to get config dir")?;
        Ok(base_dirs.get_config_home())
    }

If your binary is supposed to live in `/Applications`, by all means put its config in `~/Application Support`. If it lives in `/bin` or somewhere similar, or if its default or system-wide configuration go in `/etc`, config goes in `~/.config`.

I agree with “should not go in ~/Library/Application Support”, but why would anybody put them there? The Mac way is ~/Library/Preferences, or, system-wide /Library/Preferences, and the use of NSDefaults.

https://developer.apple.com/library/archive/documentation/Fi...:

“This directory contains app-specific preference files. You should not create files in this directory yourself. Instead, use the NSUserDefaults class or CFPreferences API to get and set preference values for your app. In iOS, the contents of this directory are backed up by iTunes and iCloud.”

If a tool doesn’t want to use NSDefaults, using ~/.config is way preferable over polluting the user’s home directory, as many tools do.

Towards the end TFA claims that Apple’s bundled command line utilities, including zsh and vim, put their dotfiles in ~/.config. They don’t. They put them in the traditional BSD place, the user’s home directory ~/. Looking at mine now, I see .bash_login, .emacs (wow! that’s old), .lldb, .lldbinit, .vimrc, .swiftpm, .z{profile,env,rc} and a few others. I see no ~/.config directory.

My personal practice when writing command line utiities for macOS is to use the macOS API to write settings (previously known as “preferences”) into ~/Library/Preferences, so they can interoperate with any GUI versions of them I might like to write, and for the utilities themselves to have command line options to control those settings. As a sibling comment suggests, you do need to avoid name space collisions. You can use a reverse DNS name, or some companies are big enough just to use their company name. They do appear as .plist files but are actually maintained by a daemon – which nicely avoids race problems with multiple processes updating settings.

If I were writing a portable utility which had a dotfile with a documented format the user was expected to edit, I would make it a dotfile under the home directory.

~/Library/Application Support is really more for per-user static data, like presets and templates, things that are known in a GUI by a string in some dialogue but not necessarily thought of by the user as a file.

I put them in a dotfiles directory and use `stow`[1] to symlink the contents to where applications expect them to be. Under that root I have a home folder that it is symlinked to `~/`, and I have and applications one that is symlinked to `Applications Support` through the `-T` argument of stow.

To this day I still have to find anything that has problems taking a symlink instead of a file.

I am pretty happy with this setup as it means that all my dotfiles are in a single root folder that I manage through a git repo.

So I don't see what the linked articled means when it says that stows "makes (unsurprisingly) no effort to support ~/Library/Application Support.". It is literally a bit of organization from your side and passing a flag.

[1] https://www.gnu.org/software/stow/

Somewhat related, a few weeks ago on Python Bytes I learned that there is a python module that abstracts various directory locations per-platform. For instance, you can use this module to find the location of the Movies directory, or the cache directory.

For example, on macOS:

    >>> appname = "SuperApp"
    >>> appauthor = "Acme"
    >>> user_config_dir(appname, appauthor)
    '/Users/trentm/Library/Application Support/SuperApp'

or in Windows:

    >>> user_config_dir(appname, appauthor)
    'C:\\Users\\trentm\\AppData\\Local\\Acme\\SuperApp'

https://pypi.org/project/platformdirs

XDG is a Linux-centric spec. If we the people want it to be OS-agnostic, it needs to be vetted and designed for that. Until then I don’t see why macOS applications must adopt XDG, despite it being my preference.

Put me in the disagree camp. The XDG spec seems like it is for X windowing-based systems, not the Mac, so that's not a reason to adopt. The author asserts what users expect, but without any evidence.

FWIW, it's not what I expect. I used Linux and Solaris extensively between 1995-2005 or so and have been a terminal using Mac user since Mac OS X public beta. My expectation is honestly that CLI programs will do whatever the heck they want and I've never heard of .config. I generally expect both configuration files and application data to reside at the root of my home directory, ideally in a subdirectory if there is more than one file.

If I could choose, I'd prefer for application data (files written by the application for its own use) to go in ~/Library/Application Support, because that's where I expect it to go. For configuration that I would edit by hand, I'm not so sure. Probably would prefer the root of my home directory, where I could at least find it easily without looking it up.

The Go standard library uses ~/Library/Application Support as well [1]. Given the Unix credentials of Golang's top folks, I would assume there's a good argument in favor of this decision?

[1] https://pkg.go.dev/os#UserConfigDir

It seems like the best of both worlds, here, would be to put the files in ~/.config/yourprogram, and symlink that to `~/Library/Application Support/org.example.yourprogram`. That would satisfy folks expecting to find it in either place. The only folks it wouldn't satisfy would be those complaining about the files being present in one of those places at all, and that seems like the least of the concerns compared to making sure people find it.

> But suppose we accept that the XDG specification only applies to some Unix operating systems, despite making no mention of this.

the very first paragraphs on specifications.freedesktop.org says this:

> Freedesktop.org is a project to work on interoperability and shared base technology for free-software desktop environments for the X Window System (X11) and Wayland on Linux and other Unix-like operating systems. > We are not a formal standards body. The standards published on these pages are active or tentative (if marked as such) specifications which desktop environments may implement to improve mutual compatibility, share code and pool resources.

Deferring to XDG_CONFIG_HOME on MacOS if it exists makes a lot of sense as it conveys a clear intent from the user and the convention has grown popular. I’m not sure that the default ~/.config from the XDG specification is automatically better than ~/Library/Application Support by appeal to freedesktop.org’s authority.

And please don’t move configuration files around between releases without really being intentional about it.

I don’t think I’ve ever encountered a command line tool that makes this mistake, hooray for me. On the other hand lots more today support XDG_CONFIG_* and don’t litter ~ with random .dir stuff. I really like the new era of CLI tools that’s trying to be excellent in every dimension. Hopefully whoever needs to see this does and gets with the program! Although if it puts this much bee in your bonnet you can always open a pr

Yeah, I broadly agree — even if I am primarily a Mac user, I am constantly annoyed by the odd tool that does that. SimonW’s “llm” tool is one of the offenders.

I wrote elsewhere that I think the solution to this is to add another variable to the XDG Base Directory Specification to explicitly opt into using XDG variables, and then to support that flag on libraries that target Windows / MacOS and which would otherwise choose mac Application Support / Windows AppData folders.

Both options are wrong on macOS.

My configurations are preferences, stored in ~/Library/Preferences.

Even better if you store those as property lists and hook into CFPreferences so I can manage them with configuration profiles and use the defaults command to query and modify my preferences without having to open the app or read some 4000 line long JSONC file with 20 lines of settings and ~4000 lines of bad documentation.

Strongly agree with the authors take. Is anyone aware of an alternative to dirs in the rust universe which follows XDG?

Ah, after all there aren't only the devs on Windows ecosystem that don't follow the guidelines where to place the configuration files.

The hint is in the name. "Application Support" has a space in it, so it's not designed to be used for CLI config.

> given that macOS is a Unix by way of BSD.

Moreover, most versions of MacOS are certified Unix: https://www.opengroup.org/openbrand/register/

Yes, they shouldn't, but try to convince people who misunderstood some poorly written Apple spec that they're wrong...

Follow the link to the XDG spec, look who is the 3rd author. There is no reason for MacOS or the BSDs to implement a systemd spec. A specific example: XDG_RUNTIME_DIR is a feature of pam_systemd and nothing else.

This is a recurring pattern that systemd documentation is sold as "neutral" standard. The UAPI group is another example of this.