Do you happen to have a link to said macOS guidelines?

You are right.

On the other side, there are many other software, which uses the same convention for user data directory location (eg. .vscode, .yarn, .node)

Does this cause any problems?

Now the location is the same for all platforms (windows, mac, linux), and also in Docker. I guess in Windows also will point somewhere into AppData directory (but also in Windows, there are many programs, which use the same convention as DbGate).

I am not sure, whether it's worth it, to make this change, which brings quite high risk, because of many supported platforms.

@ProjectInfinity Yes, these are the relevant ones:
File System Basics: The Library Directory Stores App-Specific Files
macOS Library Directory Details

On the other side, there are many other software, which uses the same convention for user data directory location (eg. .vscode, .yarn, .node)

Many developer tools do, .apps very rarely do.

Does this cause any problems?

1. I think it's a problem to have many different potential places that one app stores data. Just to delete one app's folder, you may need to look in ~/Library/Application Support, ~ and ~/.local. That's not a great user experience imo. Especially since DbGate already stores data in ~/Library/Application Support/dbgate, so I wouldn't expect it to have app data also stored in another folder.

2. Uninstall tools (including the one I use) may not recognize ~/.dbgate, so the folder is left behind, unnecessarily taking up space.

3. It's messy because it stores data at a folder level that doesn't make sense. The home folder is a collection of categories.

Now the location is the same for all platforms (windows, mac, linux), and also in Docker. I guess in Windows also will point somewhere into AppData directory (but also in Windows, there are many programs, which use the same convention as DbGate).

I don't really get this point. Sounds great for the developer, but I can't see how it makes sense for users. Operating systems are different, and require different handling.

@ProjectInfinity Yes, these are the relevant ones: File System Basics: The Library Directory Stores App-Specific Files macOS Library Directory Details

Thanks.

After reading I agree with @janproch I think the changes required outweigh the usefulness of this.

Uninstall tools (including the one I use) may not recognize ~/.dbgate, so the folder is left behind, unnecessarily taking up space.

I actively use dbgate for work and this is the size of my directory, I think it is an acceptable trade off.

du -lsh .dbgate/
58M     .dbgate/

I don't really get this point. Sounds great for the developer, but I can't see how it makes sense for users. Operating systems are different, and require different handling.

In the end I think developer convenience in this event takes precedent over saving some megabytes on a user's drive.
DbGate is after all a cross platform application and you're unlikely to have every OS/DE design/guidelines followed by any cross platform application and adding cases for each platform and their derivatives is a lot of effort.

In the end I think developer convenience in this event takes precedent over saving some megabytes on a user's drive.

In my case it's actually a pretty significant 516MB. Is the developer convenience having to deal with the migration, or is it communicating with users in issues?

DbGate is after all a cross platform application and you're unlikely to have every OS/DE design/guidelines followed by any cross platform application and adding cases for each platform and their derivatives is a lot of effort.

In my opinion, just because other apps are bad at following platform standards isn't a good reason to ignore the standards. I think we should all do our best

I've never actually seen a GUI app store data where DbGate does, because frameworks like Electron have APIs to deal with it

Similar task was already solved is issue #248