yes, it's a total pain. users send you a crash log, you see that they're on an old version, ask them to update. They say they do, you get the next crash log, and it's still the old version. And then you get a screenshot and you see 12 different versions of your .app, in the desktop, in ~/Applications, in /Applications...

Even worse when they don't copy it off the DMG. Just leave the DMG mounted.. forever.

What's the problem with leaving the exe in the DMG instead of copying it out? As a user and a developer I don't see any problem with this whatsoever unless the application is poorly built.

Oh wow, I had no idea about the unintended consequences of the DMG + App bundle installation mechanism.

Maybe the issue could be ameliorated with a self-updater built-in into the app? Not a separate daemon, but something that by running inside the app, would be able to know what's the path of the old version that should be thrown away.

Some apps offer to move themselves to /Applications on first launch.

Still, there's the possibility of users clicking "Cancel". Even then, it's a bit more code to write, test and pay for (from the POV of a client).

Wrapping the bundle inside a .pkg instead of a .dmg solves the problem "for free".

The de facto standard for this is Sparkle.framework, and it's excellent.

That's good. It's called a portable app and it reduces pollution of your environment. It's a simple partial implementation of something like Docker.

All fine and dandy until they accidentally eject the DMG and can't figure out where their browser went.

Maybe, but that's also an advantage. Often it is useful to have two versions of the same application available, for example if you are testing one of them, or if a feature or compatibility was broken somewhere along the way. Typical package manager software installation does not accommodate such use cases.