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

The XDG spec is to coordinate the userspace of Linux software, meaning both CLI apps and windowed apps. Linux needs things called standards because Linus has not bothered to write them down himself, so there is no equivalent of Microsoft telling you data goes in AppData and Apple telling you data goes in Library. Identifying it as a standard for CLI tools across OSes is just wrong.

When CLI tools do this on macOS, it is not because anyone thought 'this is a standard for macOS', it is because they thought 'with -target darwin I don't get any compilation errors. ship it!' and frequently use those locations on Windows too where they don't make any kind of sense at all.

The standardized location is Library. If you do not expect it, that is on you; you should expect it, as it is the standardized location. It is only just now that people are starting to catch up with it, instead of blind ports with absolute minimum macOS-specific code, because of libraries like `dirs` which make it easy.

Indeed!

> It has real benefits for users.

I once believed this!

> It's trivial to implement.

Nope!

I ranted about this a while back (https://bsky.app/profile/str4d.xyz/post/3lsjbnpsbh22i) but the tl;dr is that the XDG specification is imprecisely written and internally inconsistent, and there has been confusion since at least as early as 2003 about what kind of data is meant to be stored in $XDG_CONFIG_HOME vs $XDG_DATA_HOME.

A plain reading of the XDG Base Directory Specification implies (but does not explicitly say, which is part of the problem!) that $XDG_DATA_HOME contains read-only user-specific application data files (like documentation).

But the spec is interpreted by many (source: I found a single blog post that seemed to be referenced in a variety of places, such as the Arch Linux wiki) as saying that $XDG_DATA_HOME contains mutable user-generated data (like password vaults).

Those have very different properties, and it's impossible as an app developer for me to predict which of those two directories a user (or the tooling installed on their OS) is assuming can be safely deleted without consequence, and which must always be backed up.

> Yet even in the year of our lord two thousand and twenty five I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME.

My earlier rant arose from me spending several days attempting to follow the XDG specification for an app where I need to store mutable user-generated data, being unable to find any supporting evidence that it was safe to store this in either $XDG_CONFIG_HOME or $XDG_DATA_HOME, and deciding on ~/.appname instead. I do allow all paths to be overridden in the config file, so individual users can use XDG paths at their own risk (and with knowledge of their OS environment's behaviour).

Perhaps referencing this behaviour where preference files can no longer be symlinks?

> Mackup does not work correctly in macOS Sonoma and all later versions, since it does not support symlinked files for preferences.

This directory contains app-specific preference files. You should not create files in this directory yourself.