AppImage is meant to be updated using the embedded zsync info the runtime, that is the user should never have to open the app to update it.
The user needs to have something like AM, appimagelauncher or appimaged that is then able to parse the info and update the appimages using appimageupdatetool
This method also provides delta updates, meaning it doesn’t download the entire app but only a diff, see this test with CPU-X where it downloaded 2.65 MiB to update the app:
At least for appimage, it doesn’t create application launchers. And it’s 50/50 whether the icon in the window list works or not.
I also build a lot of Docker images, and container formats throw a wrench in that if that’s the only way the application/utility is packaged. So I end up building from source.
It is CLI and I’m GUI by nature, but AM is easy enough for me. Just yesterday I did a simple
am -u and got the latest updated versions of qBittorrent, FreeTube, yt-dlp etc. (I.e. the kind of program that system packages are too out of date to work safely or even work at all.)
There are other options like zap (CLI), Gear Lever (GUI) and just recently I believe the Nitrux distro came out with a complete AppImage software manager. (Checking it out, https://github.com/Nitrux/nx-software-center , it seems it pulls from AppImageHub.com, which unfortunately has largely been forgotten by developers, a lot of software is either out of date, unverifiable or completely absent. AM is much more up-to-date, pulling the latest AppImages mostly from official GitHub repos.)
Why the hate part of AppImage?
I’d say that complete lack of a single consistent way to manage updates.
I really don’t feel having to micromanage each piece of software.
AppImage is meant to be updated using the embedded zsync info the runtime, that is the user should never have to open the app to update it.
The user needs to have something like AM, appimagelauncher or appimaged that is then able to parse the info and update the appimages using
appimageupdatetoolThis method also provides delta updates, meaning it doesn’t download the entire app but only a diff, see this test with CPU-X where it downloaded 2.65 MiB to update the app:
TLDR: https://github.com/ivan-hc/AM
Just not a fan of container formats in general.
I say that as a heavy user of Docker, but that’s a different use-case.
I go the opposite way. I like the ideas of container formats lol
Easy to update, easy to uninstall, easy to migrate.
Not trying to be annoying like a kid here 😅, but why not?
At least for appimage, it doesn’t create application launchers. And it’s 50/50 whether the icon in the window list works or not.
I also build a lot of Docker images, and container formats throw a wrench in that if that’s the only way the application/utility is packaged. So I end up building from source.
Personally, I use AM. Takes care of that and more.
It is CLI and I’m GUI by nature, but AM is easy enough for me. Just yesterday I did a simple
am -uand got the latest updated versions of qBittorrent, FreeTube, yt-dlp etc. (I.e. the kind of program that system packages are too out of date to work safely or even work at all.)There are other options like zap (CLI), Gear Lever (GUI) and just recently I believe the Nitrux distro came out with a complete AppImage software manager. (Checking it out, https://github.com/Nitrux/nx-software-center , it seems it pulls from AppImageHub.com, which unfortunately has largely been forgotten by developers, a lot of software is either out of date, unverifiable or completely absent. AM is much more up-to-date, pulling the latest AppImages mostly from official GitHub repos.)
Missing dependencies. (Or wrong version of fuse)
No automated updates has be the biggest reason for me.