This is how you run a third party Firefox binary package downloaded from Mozilla:
tar xJf firefox-x.tar.bz2 ; cd firefox ; ./firefox
Most third-party commercial applications (CAD software etc.) is similar.
Obviously there is room for improvement here, for some basic sandboxing (chroot, dedicated uid and so on) and desktop integration (give the user an icon to click on, links to other applications).
It's just that Snap (and probably Flatpak too) just isn't it. Much too heavyweight and gave the users other things to worry about (disk space, updates, new types of package repositories). Something more fit for Linux culture would probably be closer to a set of best practices (this is what the executable is called, this is where libraries are put, there should be an icon here in this format), and let a thin wrapper handle it all.
Not fully. MacOS applications are nothing more than _APP_NAME_.app directory with an internal structure and manifest files that denote it is an application so when double clicking on the directory Finder knows to run the actual application binary located with-in the directory. This allows for decoupling the resources from the binary. Had to place multiple 3rd party binaries here in case the end-user didn't have them installed and used them as a fallback.
Most 3rd party applications are actually an installer script that places the contents into /opt/_APP_NAME/ or where ever the end-user requests they be placed.
The closest I'm come to mimicking Mac style on Windows to create an installer that does not actual install but extracts the contents to user's temp directory and executes the application. Needed a simple solution so the end-user just had to download and double click to run the application since they might not have admin rights to install the application.
I actually prefer the MacOS style since installing and backing up applications or moving to a new computer is the same process.
> The closest I'm come to mimicking Mac style on Windows to create an installer that does not actual install but extracts the contents to user's temp directory and executes the application. Needed a simple solution so the end-user just had to download and double click to run the application since they might not have admin rights to install the application.
I create these self-extracting packages all the time too. Getting the icons and such right on the package can be a bit of a pain so I made a quick script[0] to automate the process. You may find it useful too.
No. The Mac way is download the app file disk image, click to mount it, drag the app file from there to the Applications directory, click to unmount the image the way you unmount USB flash drives. Perhaps I would also suggest removing the disk image part to further simplify the procedure. A user should not be forced to enter any terminal commands or even understand what an archive (or an executable installer) is. We must take "stupid" users in account if we want to conquer the desktop market as they are the majority we have to conquer.
What do you mean with "the install finishes"? If you mean a .pkg install, then previous macOS version's already prompt to unmount and trash the dmg file in that case.
Parent showed the general process. The implementation can change. If you're in any recent Linux desktop, you can click on the archive and it will open in file explorer so you can copy the app anywhere. No commandline required.
That simple way is ok but it misses all the small details of the Mac os install - a canonical place to copy the installed program, a nice icon to launch it with, file associations and so on
This is how you run a third party Firefox binary package downloaded from Mozilla:
Most third-party commercial applications (CAD software etc.) is similar.Obviously there is room for improvement here, for some basic sandboxing (chroot, dedicated uid and so on) and desktop integration (give the user an icon to click on, links to other applications).
It's just that Snap (and probably Flatpak too) just isn't it. Much too heavyweight and gave the users other things to worry about (disk space, updates, new types of package repositories). Something more fit for Linux culture would probably be closer to a set of best practices (this is what the executable is called, this is where libraries are put, there should be an icon here in this format), and let a thin wrapper handle it all.