The OS X platform already has a stupid easy download-and-install process with their .app folders. It's a shame that some users prefer to instead use an alternative distribution method controlled by a centralized party rather than buying software directly from the developer.
I used to dislike purchasing from the Mac App Store too, so when I got my new iMac a few months ago I decided against migrating all the unused junk from my old MacBook and would instead start with a fresh OS X install.... great idea, right up until I realised that I didn't have all the install files for dozens of audio tools I use.
The App Store ones were a simple matter of logging in with my Apple account and reinstalling (this included Dash, mentioned here). The other tools meant hunting around for installers, realising that most of the installers now were several versions ahead of the ones I used, in many cases breaking my music projects. It also meant trawling through 9 years of emails to find licence file attachments and serials numbers so I could re-register the applications, or try and purchase upgrades for those where I couldn't find an installer with the same version as I had bought.
Giant PITA. For once I was glad that App Store apps were all auto updated through the time I had them, and I didn't have to bother with activation codes etc. In fact, I ended up trashing the fresh install idea and migrated my old machine to the new. I was actually easier to put up with old junk apps I didn't use anymore than to try and manually install just the ones I needed.
And this is a reason, why I take care in archiving installers, license keys, serials, etc for every application I use. Learned my lesson some 25 years ago, when there wasn't Internet to try to find the installer and email archive to hunt for licenses.
Good point - and I do have a registry of installers and serial numbers for my crucial development software. However, I have literally hundreds of audio plugins and utilities that are tedious to track. End of the day, it is an admin cost to maintain such an archive - and some days I think it is far easier to outsource that archival maintenance and recording to a third party... such as an App Store... :)
NB: A lot of my audio software is licenced via an iLok device. Whilst I HATED the idea of a 'dongle' like an iLok before, this hardware upgrade has made me appreciate the fact that I didn't have to worry about re-licencing all of my audio production software the used the iLok either.
> The other tools meant hunting around for installers
`brew cask install $APP`
> ...to find licence file attachments and serials numbers
Store these in 1Password (other password managers are available)
Your point about versioning is a good one though. A lot of sites don't make it easy to find older versions of their software and I don't think package managers like homebrew support versioning (although I could be wrong).
No standard update mechanism, no standard uninstall mechanism, and going from "I have this .dmg/.zip file in my downloads folder" to "I'm running this app from my Applications folder and don't have any leftovers in my downloads folder" is several non-obvious steps.
.app bundles are great, just not a complete solution.
Sparkle is the de-facto standard used by almost all apps.
>no standard uninstall mechanism
Deleting the .app file would do that for most apps. The config files might be handy to keep around if you re-install (and are inert anyway), else it's pretty easy to remove those too. It would be nice for the OS to be able to track "all files installed by an app" though in case those are installed by an installer (and thus, are not self-contained in the .app folder).
>and going from "I have this .dmg/.zip file in my downloads folder" to "I'm running this app from my Applications folder and don't have any leftovers in my downloads folder" is several non-obvious steps.
It's a few steps, but its still as obvious as things get in computing. If users can't manage that, how they'd manage USING the app?
I have known several people who were otherwise pretty competent computer users but would download a DMG, mount it, and run the app from the disk image every time.
There's a reason so many downloads include a custom background image with a big "DRAG ME TO THE APPLICATIONS FOLDER" message and an arrow pointed to a /Applications alias. This is such a common use case that I don't understand why Apple didn't just make a "This disk image is an installer" flag, and automatically prompt the user with "Do you want to install this to the Applications folder?"
>I have known several people who were otherwise pretty competent computer users but would download a DMG, mount it, and run the app from the disk image every time.
Perhaps, but they just need to be told once what to do, and it's dead easy. Having an installer is not that more intuitive -- they'd still have to be shown how to use their first one.
>This is such a common use case that I don't understand why Apple didn't just make a "This disk image is an installer" flag, and automatically prompt the user with "Do you want to install this to the Applications folder?"
Yeah, some apps do it automatically when opened from the DMG.
The goal of an installer would be that when someone fumbles through an installation for the first time with no guidance, the correct path is more obvious than the incorrect one.
The reason it's a problem now is that screwing it up is easier than doing it right, and unless the DMG's author manually added it, there's not even a hint that you should do something other than open the image and run it from there.
IMO the "some apps do it automatically" is even worse because it's inconsistent. Some apps will do it automatically and teach you that it's the way to get things installed, and then the rest of your apps won't. If checking on run and offering to move is the solution, it ought to be standardized systemwide so that users can (correctly) learn to expect it.
> I have known several people who were otherwise pretty competent computer users but would download a DMG, mount it, and run the app from the disk image every time.
Is there anything particularly wrong with doing this? I know that it's not the typical use scenario, but it doesn't seem like it causes any problems, and it's dead easy even for people for whom the correct procedure is hard.
>"Do you want to install this to the Applications folder?"
This is a sort of question that makes me hate windows. Do you want to browse files or play music? Do you want to uninstall program? Do you want to change that setting? You have unused icons, so I decided to install updates now, you can't stop me. Oh, come on!
There are a million ways it could be implemented, I didn't mean to suggest that's the only one.
For a more Mac-like method, make it a special Finder mode where instead of showing the directory contents, installer DMGs display a big icon of the app with an Install button under it.
If you really want to get at the files directly, right clicking in the DMG could give a "Show disk image contents" item similar to how app packages are handled. Right clicking on the big application icon would include an "Open" item to circumvent installation and execute from the disk image.
Config files aren't inert and can be terribly problematic if you're reinstalling to fix broken config files. Case in point updating graphics card in linux, those random nodejs apps that leave broken symlinks everywhere, and the windows registry
I'd love a to be able to download a single file representing an app, double-click to install it (it doesn't matter where it lives on disk, as long as it's predictable) and then have the system facilitate sandboxing, permissions, and one-click updates and removals.
Just like the App Store, but without the App Store.
Is draggin an .app file to "Applications" directory such a hard exausting thing to do you'd rather give up the choice of which apps you can use and functionality of said apps (sandbox!)?
Give up? I wish more apps were sandboxed! If an app can function inside the sandbox (and the overwhelming majority of apps have no problem with being sandboxed) then they absolutely should be. It's a major security benefit.
Except that there are whole swaths of tools and applications that cannot be published at all due to limitations of Sandbox, making your computer limited to a whim of someone on the other side of the world.
Yes they can, they just can't be published on the Mac App Store. But the existence of the MAS does not affect anybody's ability to distribute applications outside of it.
> making your computer limited to a whim of someone on the other side of the world
That's a really weird way to say this. Security is not a whim.
Except that there are whole swaths of tools and applications that cannot be published at all due to limitations of Sandbox
You're right, just ditch whole damned sandbox thing because a few tools won't work.
Or in an ideal world where we didn't have to decide between one extreme or the other, we could sandbox everything that doesn't have a problem with it, reserving the exceptions for those few tools that don't get along well with a sandbox. (Vetting the hell out of those non-sandbox apps, of course, because we don't want to "<make our computer> limited to the whim of someone on the other side of the world" which in this case wouldn't be Apple.)
The macOS App Store has problems but as a user, I appreciate applications that use it as the update process is a lot smoother than with applications that have their own update system.
And suspending account on PayPal for whatever reason is unheard of.
I'd say that setting up your own payment-processing/distribution will leave you with many more points of failure, except in that case you won't be able to get your story on front page.
