- In 98% of cases it is a .dmg with .app ... so drag and drop or App Store install.
   - 1% of cases it is a standard installer and that is mostly because the developer is old-school and too lazy to make a .app (e.g. here's looking at you Microsoft)
   - The remaining 1% (Homebrew/Macports) is really for the power-user, and in most cases you can just download a pre-compiled mac binary from the developers Github anyway.

> Meanwhile, 99% of my Linux software is "apt install foo" and that's it.

But `apt install foo` is a synonym for "custom installer that does who knows what" and/or "tar.gz with random crap in it"

Why ?

Your average user will blindly follow `trust me, sudo curl foo | bash` ...

And your average user is unlikely to look at the apt package build rules and/or source and/or dependency list and in the majority of cases will just answer `Y` to any questions from `apt`.

Part of my job is automating macOS software deployment. I do this all day. I can confidently tell you that your percentages are way off. I wish you were right because dragging an app bundle into Applications is obviously the correct way to do it. But alas, that is very far from the world we live in.

For example I have never used Homebrew/Macports because my 1% power-user software has been available through the developer's Github (e.g. `bazel` etc. all publish mac release binaries )

This is "a tar.gz with random crap". Convenient perhaps, but it doesn't help your argument that macOS is less of a hellscape.

But `apt install foo` is a synonym for "custom installer that does who knows what" and/or "tar.gz with random crap in it"

No, it's really not. It knows what files it puts where and can cleanly upgrade and uninstall with a predictable and standardized method. It's not that I usually care where the files are strewn exactly, it's that I want consistent installations done in a systematic and coherent way; I don't want to rely on an UNINSTALL.EXE that, like the installer, I have no idea what it does.