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

Here's a summary of the themes discussed in the Hacker News thread:

The XDG Specification's Applicability and Default Behavior on macOS

A central point of contention is whether the XDG Base Directory Specification, commonly understood to use ~/.config as a default for configuration files, should apply to macOS. While the spec itself doesn't explicitly exclude macOS, many argue it was designed with Linux desktops in mind and thus doesn't directly map or translate well to macOS conventions.

XDG Spect is Linux-Centric: Several users highlight that the XDG specification was developed in the context of Linux distributions and X Window System/Wayland environments, not necessarily for other Unix-like systems like macOS. > "Because it was designed for Linux distros, by Linux distros, not UNIX vendors." – pjmlp > "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." – cedws > "The XDG Base Directory Specification mentions Unix a few times but lists no carveouts for macOS or any other operating system." – sebws (quoting the article)
macOS Conventions vs. XDG Defaults: The discussion frequently contrasts the XDG default ~/.config with macOS's ~/Library/Application Support for application-specific data and ~/Library/Preferences for user preferences. Many Mac users expect these ~/Library locations for app data, not ~/.config. > "For clarity, is this what you're referring to as "the spec"?" – re (linking to Apple's File System Programming Guide) > "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." – pie_flavor
User Expectation and Surprise: A significant part of the debate revolves around what users expect to find where. Some argue that CLI tools should follow the XDG standard because it's a recognized convention, while others firmly believe that macOS users expect configuration files to be in ~/Library related locations and find ~/.config to be out of place or indicative of a non-native port. > "I think you should do the least surprising to the user and if that’s not what the spec says, so be it." – mbreese > "I’ve long given up on solving technical coordination problems by appealing to the universal goodness of humanity." – quotemstr > "As a decades long time Mac user, when I see something show up in ~/.config it just feels like a maladapted port." – donatj

The Role and Behavior of Directory Libraries (e.g., `dirs-rs`)

The discussion frequently points to third-party libraries, particularly in the Rust ecosystem like dirs and related crates, as a major driver for the adoption of XDG conventions on macOS. The perceived inflexibility or refusal by maintainers of these libraries to accommodate macOS conventions is a source of frustration.

Library Maintainer Resistance to macOS Norms: Users express frustration with library maintainers who prioritize the XDG spec over macOS conventions, leading to the widespread adoption of ~/.config for macOS CLI tools. > "I and others have brought this up with the dirs Rust crate maintainer but they refuse to see it this way: [link to issue] . It's very frustrating." – orlp > "It seems like the roadblock is that most cli tools don't want to think too hard about XDG at the slightest, and they delegate to standard directory libraries. Those libraries aren't normally in the business of creating symlinks, and if previous discussions are any indications, convincing them to add XDG support at all - let alone by default - seems on the same level as pleading Vim/Emacs users to just try Emacs/Vim." – tux3
Alternative Libraries and Solutions: Some users suggest alternative libraries or strategies, such as etcetera which aims to provide more platform-aware defaults, or manual implementation of directory logic. > "It sounds like https://docs.rs/etcetera/0.3.2/etcetera/index.html provides sufficient flexibility for apps that want this." – JoshTriplett > "It seems like etcetera has better defaults: [link to etcetera docs]" – tyilo
Rust Ecosystem and Dependency Management: There's a side discussion about the Rust ecosystem's reliance on external crates and its impact on compile times and development philosophy, with some comparing it to "node-esque" dependency management. > "From what I've seen Rust projects seem more or less node-esque in the sense that people just keep pulling all kinds of dependencies, not necessarily even understanding them that much." – anttiharju

The Ideal Solution: User Preference and Cross-Platform Compatibility

A clear desire emerges for a system that respects user intent, offers flexibility, and handles cross-platform differences gracefully. Various proposals are floated, from environment variables to more robust configuration management.

Opt-in XDG Support on macOS: One suggestion is to introduce a mechanism, like an environment variable, for users to explicitly opt into XDG behavior on macOS, rather than it being the default. > "I wrote a top level thread that this should be fixed by adding an explicit "I want XDG even though I'm on macOS" setting somewhere. Probably another environment variable." – joshka > "Why another one? If an XDG env var is set explicitly, that's obviously what the user wants. Just don't (necessarily) use the spec's defaults when it's not set." – OJFord
Symlinks and Migration Strategies: The use of symlinks to satisfy both conventions simultaneously and strategies for managing configuration file migrations between locations are discussed. > "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." – JoshTriplett > "The app does not need to migrate anything. Using the algorithm described above, new installations will automatically use the new paths, old installations will continue using the old paths, but can optionally be migrated at the user’s convenience." – Hendrikto
The Case for Unified Cross-Platform Approaches: Some argue against having fundamentally different file storage strategies for configuration on different platforms, especially when a single format can be managed. > "And if you're writing a cross-platform application, it's not necessarily correct to have a completely different file format on different OSes. Not all Windows applications should store all their preferences in the registry, either." – JoshTriplett

The "Application" Definition and CLI Tools

A subtle but important distinction is made between "applications" (often referring to macOS Application Bundles) and standalone command-line interface (CLI) tools. This impacts how Apple's guidelines on ~/Library/Application Support are interpreted.

CLI Tools are Not (Necessarily) macOS "Apps": Several users emphasize that macOS's definition of an "App" typically involves an .app bundle, an Info.plist, and a specific directory structure, which standalone CLI tools do not possess. Apple's guidelines for ~/Library/Application Support are seen as not directly applicable to native CLI tools. > "No, they are not. Those two are very different in macOS, where the word ‘app’ means an Application Bundle, which is a directory with a .app extension, Info.plist file, a bundle identifier, have an expected directory structure per Apple guidelines, should be installed in /Applications or ~/Applications, and so on and so forth. CLI tools, including ones that Apple ships or makes, are not apps on macOS." – goranmoomin > "A command-line tool is not the system or an app." – sebws (quoting the article)
Traditional BSD Dotfiles vs. ~/.config: Some users, particularly those with a long history on Unix-like systems, note that traditional CLI tools on macOS (and other Unix variants) have historically placed configuration files directly in the home directory as dotfiles (e.g., .vimrc, .bashrc), not 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." – SulphurCrested

The "Containers" Argument and Developer Inertia

The idea of using containerization as a solution to configuration management chaos is brought up, alongside observations about developer resistance to adopting standards.

Containers as a "Sweep Under the Rug": While some see containers as a potential solution to avoid configuration conflicts, others view this as a defeatist approach that merely isolates problems. > "That's why the long-term future of app development is containers. It is not possible, on a human level, to convince people to lift even the lightest of fingers for the common good." – quotemstr > "That kind of "sweep under the rug" attitude is even more wrong than putting a file to wrong location. Containers are good for some stuff, but duplicating code and letting badly developed software to proliferate in its own enclave is a defeatist approach." – bayindirh
Developer Apathy and Resistance to Standards: A recurring theme is the perceived difficulty in convincing developers to adhere to established standards like XDG, with some attributing it to laziness or a lack of understanding. > "The XDG specification has been around for 22 years. It has real benefits for users. It's trivial to implement. 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." – quotemstr > "It's a skill issue, moreover, PEBKAC. If there's a standard, you SHALL obey it, esp. if you're a prominent programming language." – bayindirh > "Imagine having built some software, abiding to a standard that to your understanding is the standard to abide to. Then comes people who ask you to break that standard and change your software. Again and again they come. Others ridicule your stance on social media and forums like these. It's burning out. It's free and open-source for heaven's sake! If you don't like it, fork it, patch it, make your own custom version. But stop pestering maintainers with demands." – notachatbot123

The Imprecision of the XDG Specification

A more technical critique emerges regarding the XDG Base Directory Specification itself, suggesting it's not as clear or consistent as it could be, leading to developer confusion.

Ambiguity in XDG Spec: One user points out that the XDG spec is imprecisely written and internally inconsistent, leading to debate on what types of data should go into $XDG_CONFIG_HOME versus $XDG_DATA_HOME. > "Nope! I ranted about this a while back (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." – str4d > "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... as saying that $XDG_DATA_HOME contains mutable user-generated data (like password vaults)." – str4d

The `~/Library/Preferences` and `defaults` Tool Alternative

A segment of the discussion advocates for utilizing ~/Library/Preferences and the defaults command-line utility as the more "macOS-native" way to handle user preferences, distinct from general configuration files.

~/Library/Preferences as the "Mac Way": Several users suggest that ~/Library/Preferences is the correct place for user-editable settings on macOS, especially when interacting with preferences managed by Apple's APIs like NSUserDefaults. > "My configurations are preferences, stored in ~/Library/Preferences." – wpm > "I’d prefer the convenience of an editor to read the real 5 lines and 5 lines of comments of the settings I’ve changed... and having a diffable config rather than some binary plist nonsense and relying on a clunky defaults cli. I'd even be prepared to shed the complexity of profiles for this basic conveniences" – eviks (responding to the defaults suggestion) > "The Mac way is ~/Library/Preferences, or, system-wide /Library/Preferences, and the use of NSDefaults." – Someone
Critiques of defaults and plist: Conversely, some users find directly editing plist files or using the defaults command to be less convenient than editing a plain text configuration file. > "Whereas I'd certainly have to lookup man page of the defaults tool, and IIRC it only supports editing one-key-at-a-time, which sucks for a dense config file." – swiftcoder

The `stow` Utility for Configuration Management

The stow utility, a symlink farm manager, is mentioned as a personal organizational tool for managing dotfiles across different expected locations.

stow for Organizing Dotfiles: Users describe using stow to manage their configuration files from a central dotfiles repository, symlinking them to their respective, expected locations, including those within ~/Library. > "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." – marcyb5st > "I also use stow on MacOS and have been pretty happy with it." – thehours