Why not .pkg (next, next, installer)? For the past week, I've been tweaking my startup's CLI to install as a .pkg, satisfy Apple signing, and everything that goes along with that. I've often wondered why so many companies opt for the icon method.
As a user I don’t like installer packages as much because without special utilities, they’re opaque and it’s hard to tell what they’ll do.
Of course copied binaries can cause plenty of trouble too, but I have much less of a reason to give an installed program admin privileges than I do an installer.
That makes a lot of sense. With the icon method: The user is in full control.
In our case, the CLI is part of a data sync system, so it does need a "special" once-per-hour check for new data (keeping local and mobile in sync).
I've actually been surprised how strict Apple is before it will happily let signed code run. But the average user (including me previously) doesn't know that. I think trust comes down to being clear up front.
Note to self: Add extra details/options to installer (WYSIWYG)
I moved to the Mac App Store version of OneDrive specifically because of the constant issues with the background processes it insists it must have running at all times.
The MAS version has only one of those and it works.
I like drag&drop way more than .pkg. just easier to deal with. If you do a CLI tool then maybe `brew install CLI` is the way to go instead of a pkg file?
Inertia? It's the standardized method on macOS. Macs have been this way at least since early 90s. InstallShield likewise had been normal on Windows since early 90s, so the modern MSI installers feel more normal and straightforward to Windows users.
