Personally, my best guess is because that’s the flow the product manager expected.
Personally, my best guess is because that’s the flow the product manager expected.
https://stackoverflow.com/questions/11298855/how-to-unpack-a...
% pkgutil --expand foo-1.0.pkg foo_pkg
% cd foo_pkg
% ls -Al
total 352
-rw-r--r-- 1 magervalp staff 44491 16 Mar 12:19 Bom
-rw-r--r-- 1 magervalp staff 566 9 Apr 13:51 PackageInfo
-rw-r--r--@ 1 magervalp staff 67794 16 Mar 12:19 Payload
drwxr-xr-x 4 magervalp staff 128 9 Apr 13:51 Scripts
% mv Payload Payload.cpio.gz
% open Payload.cpio.gzOn an unrelated product we learned that users ended up with many different copies of the app scattered throughout the system, if they were allowed to use the traditional bundle + DMG distribution method. Spotlight would then helpfully pick one random copy, with obvious consequences wrt. project file versioning. That is despite the DMG having the usual symlink to /Applications for a drag-and-drop installation.
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.
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".
Deprovisionig might not work right, but that's rarely needed.
As an example, I noticed the Docker installer starts off doing telemetry before anything has been installed.
Other less nefarious uses are to ask about telemetry / GDPR before installation.
Apple documentation on installers specifically says -- you don't even have to have an installer. And most software really doesn't.
I’d imagine you’d want to gate this through the process itself to ensure users have actually accepted, especially as EULA enforceability varies from place to place.