Macos Dotfiles Should Not Go in –/library/application Support
Key topics
The debate rages on: should macOS dotfiles reside in ~/Library/Application Support or follow the XDG spec in ~/.config? Some argue that CLI/TUI tools shouldn't clutter the Application Support folder, while others propose symlinks or environment variables to reconcile the two approaches. A consensus emerges that Apple's own CLI tools don't use Application Support, and that dotfiles are already "hidden" from users, whether in ~/.config or ~/Library/Application Support. As the discussion unfolds, it becomes clear that there's no one-size-fits-all solution, but a deeper understanding of user expectations and macOS conventions is within reach.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
23m
Peak period
147
Day 1
Avg / period
32
Based on 160 loaded comments
Key moments
- 01Story posted
Aug 26, 2025 at 12:49 AM EDT
5 months ago
Step 01 - 02First comment
Aug 26, 2025 at 1:12 AM EDT
23m after posting
Step 02 - 03Peak activity
147 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 6, 2025 at 1:13 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
> Put app-created support files in the Library/Application support/ directory. In general, this directory includes files that the app uses to run but that should remain hidden from the user. [emphasis added]
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.
> Probably another environment variable
Having any of the existing XDG_* environment variables set is an incredibly-clear indication that the user wants the XDG spec followed.
Where is XDG on Open Group standards?
Much like the original author, my opinion is that you should do the least surprising to the user and if that’s not what the spec says, so be it.
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.
Many good command-line tools manage their config files automatically, in addition to allowing the user to hand-edit them. I don't think that materially changes this, though: people may still expect to find them in `~/.config`.
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
I now use a combination of xdg + known-folders manually:
to get the config directory:But the real distinction is that the "Apple App" manages its preferences in-app. The "CLI app" does not, the user is expected to manage this configuration themselves.
XDG's spec doesn't make such a distinction, so you’re advocating for a new competing standard.
I don't think Apple’s documentation intends to cover command line programs, but… in the absence of any concrete rule, putting your files where most programs on the system do is a reasonable choice, and that place will never be ~/.config/ on macOS.
Apps like homebrew that default to the library but support XDG_CONFIG_HOME if explicitly set, are a decent compromise, though.
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.
Consider https://specifications.freedesktop.org/basedir-spec/latest/
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.
I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity. The only thing that works is to sandbox applications at tightly as possible and direct all their access to the external world through narrow interfaces that do their best to limit shenanigans.
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.
> I still see TypeScript developers complain that it's "too hard" to comply with "this BS" and just stick files in $HOME.
I normally use this phrase sarcastically, but this time they really deserve it. It's a skill issue, moreover, PEBKAC. If there's a standard, you SHALL obey it, esp. if you're a prominent programming language. I mean, even my small utilities obey that. But that's Microsoft...
> I've long given up on solving technical coordination problems by appealing to the universal goodness of humanity.
Thanks for the good fight, we can take the torch from here and continue the challenge. No hard feelings here.
> The only thing that works is to sandbox applications at tightly as possible
Don't be so defeatist, though.
A mature technologist must be pragmatic if he wants to get anything done. Isolation technologies work. Scolding doesn't. We tried.
From what I have seen, not every human being is same. Categorizing them as clones of each other is falling into a false dichotomy.
> they're not about to start now just because you say so.
There's a quote I'm quite fond of: "You don't have to cut with the sword of truth, you can point with it, too". I don't "say what to do" to people and expect them to obey me. I produce examples, and put them out, and tell them politely. If they take the example, that's good. If they leapfrog me and show me a better one, that's great. If they ignore me, that's OK.
Not everyone will follow, and that's OK. Even I get upset by some people who doesn't do the correct thing. That's OK too.
We should be different, try different things, and find the correct way by mistake, or reach dead ends by doing everything right. My experience says both is possible, and even though the process is infuriating, that's OK too. This is called life. We can't control and know everything.
> A mature technologist must be pragmatic if he wants to get anything done.
There are places to be pragmatic, and there are places to experiment. Again, another false dichotomy. I did go great lengths by mixing the two, for example.
> Isolation technologies work.
Yeah, I also use them in various use cases, but never to sweep my incompetence under a proverbial rug. Instead, I skill up, do better. Surpassing myself in every iteration is the best dopamine hit I can get.
> Scolding doesn't.
You shouldn't be scolding anyone over any mortal matter like programming though. There are better ways to communicate, again from my experience. YMMV, IANAL.
> We tried.
You may have tried and I deeply respect that. But I'm a dense person who doesn't understand sometimes and do as I please, and apparently it helped me go places. So, I'll continue to be a dense person.
They do the same on windows. Recent microsoft tools are written linux-first, even dotnet.
That'd be interesting, honestly.
*: I have seen it all. I don't buy the OpenWashed Microsoft of today.
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).
"There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME"
Where are you seeing "read-only"?
And why would it not be safe? What kind of user specific documentation did you think should go there and even if you did, why would you think it could be randomly removed by something else?
$XDG_CONFIG_HOME is clearly meant for data that would otherwise be in a configuration style dotfile. This is the sort of configuration that that users may well want to sync between machines such that a dotfile manager should include them by default. (That said, there may be some data from some of the other XDG directories worth syncing too, but generally a dotfile manager should not include those other folders in full by default.)
Beyond that the spec defines $XDG_DATA_HOME as "base directory relative to which user-specific data files should be stored.". The default path ($HOME/.local/share) might suggest that this should be read-only data, but it actually is read-write.
The description of the $XDG_STATE_HOME makes it quite clear that $XDG_DATA_HOME read-write: "The $XDG_STATE_HOME contains state data that should persist between (application) restarts, but that is not important or portable enough to the user that it should be stored in $XDG_DATA_HOME". This makes it clear that important and portable data should be written to $XDG_DATA_HOME.
And thus we also have $XDG_STATE_HOME. The list of examples that follow the previously quoted sentence make it clear that this is stuff that gets persisted, but if it were omitted from a backup, the user will probably not care too much (i.e. stuff like logs, history, set of open files, undo history, etc.
$CDG_DATA_HOME does also include any read-only reference data, which should be searched for there, and in $XDG_DATA_DIRS (which defaults to "/usr/local/share/:/usr/share/").
It could certainly be argued that read-only reference data and read-write user data should not have been mixed. After all Unix does keep them separate that at the top level `/var` vs `/usr/share`, but the spec authors apparent felt this distinction was not necessary at the user level.
> $XDG_DATA_HOME defines the base directory relative to which user-specific data files should be stored.
And really, the difference between XDG_DATA_HOME and XDG_CONFIG_HOME is subjective anyway, each application will have its own requirements, so I'm not convinced it's even possible to define these completely precisely.
Personally, I would pick between XDG_DATA_HOME vs XDG_CONFIG_HOME based on whether the application manages the files, or whether the user is expected to manage the files themself. This isn't based on any wording in the standard, but just a pattern I've commonly seen
Don't blame people for doing what 90% of apps do and assuming everyone else is correct.
I wholeheartedly agree about the containers part though, just have everything within a folder in a container somewhere so I don't have to keep googling where X stores Y and still failing half the time.
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. Like apparently serde the library is responsible for most of the slow compile times people associate with Rust, because deserialization/serialization is kind of a common thing to do in an app.
Happy to be corrected on my statements, not 100% on anything.
edit: apparently the behaviour in Go std library is the same, heh https://news.ycombinator.com/item?id=45022680
My experiences as well. Try to "cargo build" any projects, and you will immediately see the node-esque problems. It does not fill me with hope.
Why is this normalized?
In practice, there are a lot of well known and well maintained Rust crates for core functionality. It has also inspired some good competition among different crates to serve different purposes, such as the different command line arg parsing libraries.
I don’t find it to be a problem at all, but I know some people get triggered when they install a package and see it download different dependencies.
The main cost of compile times is Generics. Rust generics use "Monomorphization" which generate different binary code for every use of a generic type.
serde leverages generics everywhere and it generates the serialization code for every type you make serializable. So when you use `serde_json::to_string(MyType::new())` it follows calls a code path just for serializing MyType to a json string.
The upshot: It's incredibly fast, there's a lot of inlining and other compiler optimisations that can used because of it. No runtime reflection (Which is how Go does a lot of it).
The downsides: Takes a long time to compile cause of all the extra it's generating. Also can inflate binary sizes at bit.
Other languages like Go mostly use run time reflection for Json. Rust doesn't have much runtime reflection so doing it here wouldn't be possible
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.
I don’t see any “pestering” in the linked issues. They’re polite and well-written with supporting links.
This is how it’s supposed to be done. Suggestions for improvements or issues noticed go into issue requests for discussion. If the maintainer doesn’t want to do it, a polite and concise explanation is typical.
The refrain of “just fork it!” is a cop-out. Forking software so you can maintain a fork forever isn’t a trivial decision. It’s not helpful to the community to have to choose between a lot of different forks that have minor differences.
I agree that open source maintainers don’t owe anyone anything, but I think this mentality is being taken too far when with the “maintainer is always right” mentality combined with blaming the issue starter for the maintainer’s behavior.
Fork and move on with your life.
Suggest it once, discuss it, get refused, move on. Instead there are tens of comments and above is a complaint about an additional ticket for the same issue.
I am not saying that maintainers are necessarily right, but they are in their right to build their project how they like it. It is a bad pressure and force if people continue to ask for things that a maintainer has already ruled out. What's the goal otherwise, caving in due to pressure and stress?
but CLI tools are applications
CLI tools, including ones that Apple ships or makes, are not apps on macOS.
I’m sorry, this is my pet peeve as well and it’s very frustrating to see this ‘CLI tools are apps’ argument from developers who are not familiar with the Apple guidelines, and then argue about on an ideological basis.
Most libraries that use dirs-rs are doing so because they don't want to have to think about those things. So if there were a library that did it right, you'd probably have decent adoption if it's a simple crate replacement.
When writing the files, check the old location first, fall back to the new one. When reading, check check the new location first, fall back to the old one.
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.
You are really making this more complicated than it needs to be. Just do it yourself, to be honest. It’s like 3–5 lines of code. Introducing a library just complicates it.
> copy the files, delete the old dir, them and then read from the new one. […] What if copying fails mid-way?
As I said: You don’t need to copy, delete, or move any files. Just support both modern and legacy paths, and let the user take care of the migration, if they choose to.
> What if it's a symlink?
Again, why are you making this so complicated? Just try to read the file. If it fails, check the next location.
I'm aware it mentions Linux specifically, but this is golden:
> From this point on, the number of dot-files and dot-directories can only shrink as the remaining applications get fixed and start conforming to the XDG base directory spec, while no new dot-files and dot-directories can be added to your home directory.
As is original reasoning for not using ~/.config from https://github.com/dirs-dev/directories-rs/issues/62#issueco...
> As Apple keeps tightening its after-sale ownership of macOS appliances, it's becoming increasingly unlikely that randomly dumping stuff in $HOME will keep working.
I get the feel he just does not like macOS?
If I ever have time, I would love to fork this repository, patch it to support XDG_*, and actively work to advertise it across the rust ecosystem. If user wants to use different location on file system to store configuration files, then let them. Stop trying to dictate what users want.
I think the Application support people have a stronger argument. Nowhere does it say store it in ~/.config for CLI tools. Also it seems weird to store user preferences in two different locations based on if it’s a CLI app or a GUI app. What if you have both interfaces?
I’m not saying that Application Support is the better solution, and if people feel that there should be a distinction between CLI apps and GUI apps they should push for Apple to update their standards. Repeatedly harassing an open source maintainer to relitigate an issue they’ve already decided on is counter productive and a waste of the maintainer’s time. I would be frustrated if I was him as well.
> `choose_base_strategy()` and `choose_app_strategy()` will use the XDG strategy on Linux & macOS, and the Windows strategy on Windows. This is used by most CLI tools & some GUI tools on each platform.
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.
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.
I'd honestly be fine if none of them did.
> This directory contains app-specific preference files. You should not create files in this directory yourself.
Also
> 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.
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 (instead of the made up 4000000) 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
[1] https://pkg.go.dev/os#UserConfigDir
On the other hand, you can be more flexible and allow the user to pick how these are determined, as the Rust crate etcetera[1] does. This gives you the best of both worlds.
[1] https://docs.rs/etcetera/latest/etcetera/app_strategy/index....
From my perspective it makes sense as a default for go, which may be used to make either apps (things with bundle identifiers that go in /Applications) or CLI applications (which I wish would use ~/.config, but I understand that that's just my preference)
POSIX exists, because out of UNIX System V, every clone went down their own merry way.
So why is there a problem?
This directory contains app-specific preference files. You should not create files in this directory yourself.
The system provided interface in XDG apps is the XDG path - the Apple code there implies writiing a GUI app as none of the paths it says are not updated by the App ie no manual updates.
I think the exception is app bundles which also include some sort of auxiliary CLI utility that usually gets symlinked from its location in the /Application app bundle onto the PATH. For example the VSCode `code` CLI tool.
Basically anything that's a pure CLI binary would never be in /Applications anyway.
Defaults should go in /usr/. It is package developer / maintainer territory.
System-wide overrides should go in /etc/. It is the purview of the system administrator. Importantly:
> Programs must work correctly if no configuration files are found in /etc/.
User-specific overrides should go in XDG_CONFIG_HOME, with a fallback to ~/.config/.
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.
The issue is that often everyone assumes that XDG_CONFIG_HOME is ~/.config
The idea of having a variable is that it could be anywhere,
The default value, when XDG_CONFIG_HOME is not set, is by specification ~/.config. It does not (and should not) default to a different value on OSX.
And if you choose to just trust library authors, you are putting their ideas there instead. There’s that Rust crate that uses XDG on macOS, for example.
Why not just CONFIG_DIR?
Doesn't matter. This whole situation is a mess, and it's still a mess in the year 2025. Clearly existing operating systems can't be changed significantly enough to change anything like this.
but we're all still afraid to write new operating systems. We cling to MacOS, FreeBSD, Linux, and Windows as if our lives depend on it. Our lives do not depend on it.
If we want a saner OS, we could have it, but we don't want it bad enough, I think. It's easier to just deal with the piles of horse manure that has been piled on top of everything. So we have a rather active bikeshed discussion on HN about whether or not to use XDG_*.
We want to bikeshed more than we want to fix anything. Like all communities, this one also disappoints me.
This is a recurring pattern that systemd documentation is sold as "neutral" standard. The UAPI group is another example of this.
Also, XDG_RUNTIME_DIR is a just a directory. Since when did directories become a systemd feature?
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.
This would mean that essentially all edits to the configuration must be performed by the CLI tool itself? Because macOS preferences aren't really intended to be edited directly by the user. That feels like a totally different category of configuration than what we're discussing here. Though it certainly provides some nice functionality.
Don't force your users to go through some custom sequence of CLI commands that they first have to spend 5 minutes learning. There should be no learning curve for a one-time setup.
It's a lot worse, IMO. We're all fluent in our text editor of choice, we all know the rough format conventions of dot files.
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.
If your tool provides a TUI/GUI for editing preferences, that'd be a different story.
> It’s certainly no worse
It's much worse, you don't get persistent undo from previous edits, indication of current changed and committed data, syntax highlighting, regex search, etc, etc.
Vim, Emacs, and Swift Package Manager do in fact support XDG. Also Git as well. But Vim doesn't create config files by itself and Emacs is no longer distributed by Apple.
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/
> […]although macOS will regularly replace your symlinks with copies of the destination files
I’m curious about this claim from the article - to what extent is this true?
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.
Weird.
> Elsewhere, Reilly Wood rebukes a user asking if there would “be any downside to just not using Application Support ever” by saying that “[Nushell would] no longer be following the macOS Standard Directories guidelines.”
> We’ll read through those guidelines in a minute, but it’s not entirely clear to me that they’re relevant in the first place. The XDG Base Directory Specification mentions Unix a few times but lists no carveouts for macOS or any other operating system. If ~/.config is accepted as the standard location for configuration files on Unix-like operating systems, then surely it would be the standard location on macOS as well, given that macOS is a Unix by way of BSD.
> But suppose we accept that the XDG specification only applies to some Unix operating systems, despite making no mention of this. The macOS Standard Directories documentation starts by stating that “[w]hether provided by the system or created by your app, every file has its place in macOS”, and honestly we could stop reading right there, because a command-line tool is not the system or an app.
I could write a specification that says where files should go on macOS, and I could even get people to agree with me. That doesn't mean macOS or anyone else needs to care what we think
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.
I wish I expected CLI programs to put their config in ~/.config, but I do actually expect them to just dump them into ~ annoyingly
For example, on macOS:
or in Windows: https://pypi.org/project/platformdirshttps://github.com/tox-dev/platformdirs/issues/368
Meh. An application is an application.
To make it extra fun, my $HOME directory is immutable:
(Simply setting it read-only would work too.)Preventing arbitrary writes in $HOME breaks things, but it's actually quite rare.
I should document this setup. Or perhaps it's better to keep the madness to myself...
FWIW I use firejail so applications cannot run anything in $HOME and temporarily (heh) mounted tmpfs (two separate options).
I assume this breaks vscode? Would love a writeup if you have time
No part of macOS's desktop uses or specifies the XDG standard, it's not a POSIX standard nor a standard embraced by the OS. Following it is applying someone else's custom.
As another commenter mentioned though, ~/Library/Preferences is likely the more correct location on macOS.
It really, really isn't. That's where the macOS defaults system stores its data and shouldn't be hijacked for anything else. There's gazillions of files in there, most of which aren't grouped by directories. It's primarily meant to be accessed programmatically. It'll be painful and error-prone to manage CLI configs in there.
macOS is a unix, and there's no reason to make CLIs work partially like a Cocoa application. Breaking compatibility with other unices isn't worth it, especially when dotfiles work on macOS just like it works elsewhere.
[0]: https://pkg.go.dev/os#UserConfigDir
Moreover, most versions of MacOS are certified Unix: https://www.opengroup.org/openbrand/register/
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.
54 more comments available on Hacker News