In terms of apps no, it doesn't or basically it is the Mac App Store. You basically publish your app with all the dependencies and target a specific OS version which guarantees certain baseline frameworks. Apart from that, any update means publishing a new version to the App Store (if you are there). If you are self hosting the app, you need something like Sparkle to trigger app updates.
In terms of proper package management a la yum or apt, there is homebrew of course.
I used MacPorts back in the 00s and early 10s but switched to Homebrew when it came out because it was less hassle.
Wanted to give it another shot with my latest clean OS install, but wound up installing Homebrew again due to broken packages on MacPorts. Probably should’ve tried to contribute by fixing those packages but didn’t have the time or mental energy available at that point in time.
Installation is similar just a standard mac install.
apps are the same.
The only difference is that Homebrew gets confused if you install your code or another build in /usr/local oh and Homebrew forces you to use non standard permissions on /usr/local
Back when I switched, it wasn’t unusual for MacPorts packages to not compile for some reason or another, and at that point my skills in that realm were lacking which meant I had little ability to fix these issues, rendering its technical superiorities over Homebrew moot.
Homebrew was less hassle in that most of the time, it successfully installed things and when it didn’t, it was fixed in short order.
Since then I’ve become much more capable of diagnosing and fixing broken packages but it’s still not something I’d like to spend my time on if I can help it.
As a more technical user who is aware of Sparkle, I recognise the Sparkle updater and I appreciate it. In fact, I miss this on Windows, where each app updates differently, and most will just throw you annoyingly to the install wizard all over again.
> Doesn't that leads to the situation on windows where every single app is phoning home at startup?
1) It's a setting/preference. The polite/respectful app developers will ask users whether they want to automatically check for updates.
2) It's periodic. Developers can set the default to whatever they prefer — daily, weekly, monthly, etc. — and again the polite developers may give the user an option here too.
Usually the point of "software update frameworks" is to make the app phone home and check if there is an update isn't it?
I mean you can have an option to not make it check for updates if you want to provide a privacy option for people, but that just makes it a manual click-to-check-for-updates. Most people would probably leave the "check for updates on start" checked.
Can't see how that's a difference based on what OS you are on? I use Squirrel/Velopack (the equivalent for Windows I guess) and the usual way of managing updates is to have an update check at startup, or an interval (e.g. every hour).
>Can't see how that's a difference based on what OS you are on?
I have been a linux and openbsd user for the most part of the last 3 decades with only short stints on windows in a professionnal setting or when fixing up my partner's issues and nearly 0 experience of macOS apart from launching it in a VM out of curiosity 3 times so I was genuinely surprised and not aware of potential restrictions of app store. I know on windows there is the microsoft store + chocolatey that can handle apps updates (and possibly other projects?).
I have had the occasionnal java app installed in /opt from a tarball or an appimage but for me apps individually phoning home is more the exception than the norm. I usually have one process connecting to n repos, n being less than 5 usually and usually only when I am querying it manually. In recent years on Fedora I've let gnome software app connecring automatically and I guess with some flatpaks installed I am querying 2 flatpak repos (fedora +flathub) more but that's about it and most of our distro packages have telemetry and users counts disabled.
What I mean is: assume you use a software update system (Whether it's a "store", a "package manager" or just my own system I set up for one single app - it's irrelevant). The system needs to "phone home" to query what updates there are. There is no way around it. And unless you want to submit to a centralized store (Steam, a linux package repository, Windows store) then you are usually left to make the call individually for each app. And that applies regardless of OS of course. A self-updating linux app that dowloads its patch from acme inc is no different from the same app running under windows. It might be more or less idiomatic to do so for an individual app under different OS'es, but technically it's of course the same thing.
Many open source (and even proprietary apps) apps get published using homebrew casks [1]. Although they usually use that as supplementary method. And sometimes it is done by volunteers.
You can use homebrew to install regular apps as well, thanks to the casks feature. There's probably some apps that aren't available as casks, but usually everything I need is available already.
Mac classic had full compiled applications that you would drag to your applications folder. This is the same when it's distributed by dmg and told you are to drag to the Applications folder and using Sparkle on this is a common method to update or to just give another dmg. Another way you can distribute your app is to use a dmg to with a pkg file in it and this launches an installation wizard very similar to what you would see on windows. Then there is homebrew that has a series of ruby formulas that can do nearly all of the above. Obviously there is the Mac App Store.
