Linux

I'm a Flatpak user myself, but a lot of those arguments against AppImage are outdated or invalid. Here are my counterpoints:

Usability issues

GearLever solves all the problems mentioned.

Updates

There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don't want to use GearLever, there are other updaters like AppImageUpdate.

The lack of repositories
Appimages don't even have a central place where you can find them, not to mention download them.

This is blatantly wrong - AppImageHub exists for this very reason. There are also GUI frontends like AppImagePool which makes it easy to discover/download/install them.

Lack of Sandboxing

That is a fair point, however, AppImage never claimed to be a sandboxing solution, and for some use-cases this can even be seen as an advantage (any Flatpak user would've at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes). But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you're actually running an untrusted app.

Random location
[..] A necessary step would be mounting the entire /home non-executable. This is no problem for system apps, or Flatpaks, but where do you put Appimages now?

There would need to be a standard directory to put such files in, which is normally the PATH. But this is also the easiest attack goal for malware, so PATH would be non-executable as well.

I completely disagree with making the entirety of /home as non-executable, when $HOME/.local/bin is recommended by the XDG standard as a place to store executables. As long as $HOME/.local/bin is in the XDG spec, I'll continue storing my executables there. If you disagree, go argue with the XDG guys.

Duplicated libraries

This is a fair point but "they include all the libraries they need" is the entire point of AppImage - so mentioning this is pointless.

If users would really install every Software as Appimages, they would waste insane amounts of storage space.

Then it's a good thing that they don't right? What's the point of making hypothetical arguments? Also, this is 2024, storage is cheap and dedicating space for your applications isn't really a big deal for most folks. And if storage space is really a that much of a concern, then you wouldn't be using Flatpak either - so this argument is moot and only really valid for a hypothetical / rare use-cases where storage is a premium. And again, in such a use case, that user wouldn't be using Flatpaks either.

Finally, some distros like Bazzite already have the above integrations built-in (GearLever/AppImagePool), so you don't even need to do anything special to get AppImages integrated nicely in your system, and there's nothing stopping other distros adding these packages as optional dependencies - but it's kinda moot at this point I guess since Flatpak has already won the war.

Personally, I'm pro-choice. If AppImage doesn't work for you, then don't use it, as simple as that. Stop dictating user choice. If AppImage is really as bad as you claim, then it'll die a natural death and you don't have to worry about it. What you really need to worry about is Snap, which has the backing of Canonical, and some dev houses new to the Linux ecosystem seem to think packing stuff as Snap is an acceptable solution...

I agree with this, but as an app developer, can I just say, Flathub’s documentation is an absolute abomination. It is so bad, that I’ve tried 3 times to publish an app and have given up each time. I can build a local Flatpak just fine, but getting it on Flathub is just so convoluted and bad.

AppImages are ridiculously easy to build and distribute, just a pain to actually use. And even then, they’re not that much of a pain.

AppImage is great at what it does - provide an ultra-low effort packaging solution for ad-hoc app distribution that enables a developer who won't spend the time to do rpm/deb/flatpak packaging. There are obvious problems, security and otherwise, that arise if you try using it for a large software collection. But then again some people use things like Homebrew and pacstall unironically so ...

oh boy here we go I strongly disagree with this article

While complex .tar archives (like firefox) may seem messy, they integrate many different things. An installer script takes care of placing a .desktop entry, you can have an updater script, a LICENSE, README and more. Those are all missing with Appimages.

.tar ARE messy, sometimes they don't work right, dep conflicts, etc. An installer script can be shipped with an appimage anyways. Moot point IMO

Apps installed with the system package manager get their .desktop Entry in /usr/share/applications, installed Flatpaks get their entry linked to ~/.local/share/flatpak/exports/share/applications/, user overrides and other installs can be put in ~/.local/share/applications/.

Appimages have no desktop entry, so they have (currently) no icon on Wayland and they don't appear in your app list. Desktop entries are a standard, used by everytthing but Appimages.

see above

Instead users follow strange habits like placing the files on their desktop, which is a highly discouraged "Windows workflow" (symbolic image) and not even supported on many Desktop Environments, most notably GNOME.

Who discourages it? I personally prefer this myself, lack of desktop icons is a common complain for stuff like GNOME...

This is both a usability and a security issue. Traditional Linux apps, even if they are cross platform, don't have updater services, as package managers are way better at doing that.

I disagree that this is better. A personal issue but I Much prefer when apps can update themselves.

This means, packing as an Appimage either requires to implement an updating service, on a platform that doesn't need that, or to have no updates at all.

Instead users need to follow an RSS feed, get a mail, or manually check for updates, which is horrible UX. Then how do they update?

Is this really a massive issue? There have been appimage stores in the past. Self updating appimages really isn't that hard either. If this was a massive issue, you could do something like obtanium for android which could easily automate the process.

Appimages don't even have a central place where you can find them, not to mention download them. This is extremely insecure. Modern Application stores and every well made Linux repository uses cryptographic (mostly gpg) verification, which secures the authenticity of the software. You can be sure you downloaded the real package.

I'd argue it makes little difference. But yes, Downloading things from the internet is more unsafe then downloading from a repo or a "curated" service. So we can grant one here.

There is no updating mechanism. On Android you may also update by downloading .apk files, but once installed, the .apk needs to be signed with the same key, otherwise updates are blocked. With Appimages... you just delete the old .appimage file, download the new one, change the name to remove the version and hope your .desktop entry didn't break.

This is how you get malware.

the risks seem blown out of proportion here. As long as you are downloading from the same place, the risks are significantly smaller in reality, not gone, but smaller.

They are not well maintained

There is a well known "bug" on modern Ubuntu, where Appimages lost their "works on every Linux Distro", because they are built for the outdated libfuse2, while Ubuntu now uses libfuse3. The fix is to install the outdated version of libfuse (!), and this is still not fixed.

An application format, that is incompatible with the latest version of its core dependency, is broken.

This is a very minor issue, i've had way more issues with traditional repo packages then I have had with appimages.

Lack of Sandboxing ...

I find this to be a benefit myself, I have had countless headaches with flatpak applications and their sandboxing. everything from devices not being recognized, weird storage issues and more.

Random location ...

Another moot issue. $HOME/.local/bin is an XDG standard, so unless we pretend that XDG standards aren't "one of the major standards" this is just wrong. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Duplicated libraries

Appimages bloat the system. They include all the libraries they need, and unlike system packages or Flatpaks, they don't share a single libary. If users would really install every Software as Appimages, they would waste insane amounts of storage space.

This also completely discourages efficient and up to date packaging, and the attached risk of outdates libraries is hidden away in that .appimage archive.

and? When you need only a couple appimage files, space I find is smaller then flatpak, it only becomes when you need a lot of applications.

Appimages are not needed Flatpak solved many Linux desktop issues at once ...

None of these provide reasons as to why appimages aren't needed. Appimages still offer a lot, for one I can just download and run it I don't need to worry about installing and uninstalling application when I just want to try it, I don't need to muck about trying to get an app into flathub or starting my own repo, when a user has a problem, I can just tell them to run the new appimage instead of trying to get them to compile it.

Appimages also let me do fine grained control over the dependencies. No unexpected runtime updates, I can compile the deps with flags/features I want to support, and disable flags/features I don't want to support, Users don't need to download a stupid appstore or use CLI (not a single appstore i've used to date isn't hot garbage, I hope cosmic-store will be different).

Odd, this random github rant didn't seem to sway my opinion.

To hell with user choice, only flatpak

Now I WILL get judged for this but hear me out... AppImages are useful for apps that will not get on Flathub. If you have an app that cannot get on Flathub (like a pirated Minecraft Launcher), you will be thankful developers are using AppImages for them. In this case, they're unlikely to use snaps (alt repos for snap are possible but difficult from what I've heard) and maintaining a flatpak repo just seems like overkill for a single program. So for cases like these, I'm glad to see these packaged as appimages

AppImage is a nice way to have an app on an USB stick, remote server or for archival. But for normal app usage, why?

When I was first getting into Linux, Flatpak wasn't a thing quite yet. I ended up installing software in all of the following ways:

• A .run file. Simplify3D (commercial 3D printer slicer) did this, it was kind of a literal word for word translation of the Windows .exe installer system. Please don't do this. See also install.sh. Just don't do this.

• A .tar.gz file full of the executable and its assets with no further elaboration. This happened a few times but I really remember FTL: Faster Than Light did this when I bought the game directly from them rather than on Steam, and they were nice enough to link it to a Steam key for me. This'll work if you're handing out a thing you made to a couple other people, don't distribute like this please.

• Clone my git repo. I'm going to type this slowly so that it will best be understood: Git is for people who are contributing to code, not for people who just want to run it. Do not ask end users to compile from source.

• Ubuntu PPAs. This one seems to have died; it's been a couple years since I've seen anyone suggest adding a PPA. Good, they somewhat sucked.

• Pip. There are way too many end-user applications that are distributed with Python's package manager. No. Bad.

• Alien. For a brief time the driver for my printer was only distributed as a .rpm, I was on a .deb based system. There's a thing called Alien that lets you do that.

• Loose .debs. Haven't encountered this one in awhile either, but...could be worse.

-Snap. No. Just. No.

Compared to almost all of these I'd prefer an AppImage. For example, go look at the process of getting an up to date copy of Chirp, the amateur radio programming software. The instructions are kind of "build it yourself," they are flawed and borderline incorrect, and include no uninstall instructions. I would vastly prefer they just package the damn thing as an AppImage.

Compared to AppImage, I almost always prefer a Flatpak. Flathub is built into my distro's GUI app center and is almost transparent to the user. Using Flatpaks with the terminal is complete rectal pus, but for most end users who prefer to do things graphically Flatpak works pretty well most of the time. It is not completely seamless, like Flatpak seems to suffer from all the drawbacks of sandboxing with none of the benefits.

If you are distributing to a wide audience, use Flatpak or publish to the various standard repos. If you're a little niche thing that might distribute 200 or 300 copies ever, AppImage is probably simpler. Otherwise just...keep your repo private.

The only use case for Appimages
If users want to carry applications around on a thumbdrive, or run on a fully immutable system like TAILS, Appimages may be needed. But this is the only target, and it is not a standard use case.

I guess I agree. This is precisely the case where I have ever used them. Namely to have a portable executable of my password manager on a stick together with a backup of the password database.

I had no idea they were being used elsewhere.

Counterpoint: I don't like having more than one package manager on my system, which means things like Flatpaks and Snaps are out. With AppImages, I just double-click on the executable and off it goes.

We're also regularly debating Flatpak here. That password managers don't tie into the browser and the desktop themes don't apply. It's also not the best solution and regularly confuses newer users.

I don't get why we didn't just do it macOS style; bundle everything into one directory with a standardised structure and wire up file managers etc. to run the correct executable inside it.

As a humble linux user of the last year or two my experience has been that anything that is not in the Debian repo is a confusing nuisance. Nobody told me how to get appimages to integrate with my desktop. I had to rummage the internet and learn how. Compare this to a single click in Gnome software or simple command in the terminal for apps in the repo. I also installed flatpak, so I could get programs that weren't available in the repo but nobody told me I would have to install and rummage Flatseal to enable them to work properly, that it would make my backups and restores take 900% longer and would rinse my data when they need updating. It's been annoying enough that I've ended up learning how to install from source as well. Maybe it's cool that I've learned how to do all this new stuff but to be honest I just feel like I've had to do loads of extra head-scratching and unnecessary work. I did it willingly because I've been committed to not being held back from using open source software but I couldn't expect my friends and family to do any of this, so if I do get them onto Linux I can't recommend these programs to them.

Current tier list:

• Debian repo
• .deb downloaded from a website!
• Enjoy using application, go for a bike ride.
• Make sure I'm free for a couple of hours, install from source.
• Appimage
• Do without given application
• Flatpak

I’m not a fan of alternative packaging solutions. Never been. If it’s not in Debian’s repositories then I don’t bother with it. Some would say that’s close minded as not all packaging solutions are bad but when you use a stable distribution like Debian the native packaging solution is a lot easier to maneuver and troubleshoot than flatpaks and the like.

I use Appimage this is a tool which make it easy to install Appimage and update it

https://github.com/ivan-hc/AM

Some of these apps can't work as flatpaks at all, because they require more access to the system, e.g. Davinci Resolve. AppImage allows that. I mean, heck, even Ubuntu runs a virtual filesystem in order to allow its Snap Firefox to access the Dictionary that lives "outside" its sandboxing. So, yes, there are cases where AppImages do serve a purpose. Not most cases, but a lot of cases.

I'll be voted down but...

This is the shit you get from kids who grew up with "app stores."

AppImages as a universal packaging format seem fun in that I've had loads of issues getting them to run properly on different systems. I'm sure they're handy for some stuff but haven't personally enjoyed them.