@mtjcreative AppImages are an interesting case. They do work on basically all distros. They're... kind of more bloated and less bloated at the same time.

With Flatpaks, certain dependencies can be shared across all Flatpaks installed on the system, saving space. AppImages cannot do this. But, AppImages can use dependencies that are already natively-installed on the system (good for "ubiquitous" stuff like glibc, gtk, qt, etc.), whereas Flatpaks are forced to have their own "sandboxed" copies.

@mtjcreative So like, imagine you're on a system which already has glibc and gtk3 installed (most distros), and you have an app that needs both of those.

When you install that app as a Flatpak, Flatpak installs its own copies of glibc and gtk3 - meaning you now have two versions of those libraries on your system: the native versions and the Flatpak versions. But, that's it. If you install another Flatpak in the future, it'll reuse the Flatpak versions and won't install them again.

@mtjcreative With AppImage, there are two options:

1: The app could be made to just use the glibc/gtk3 that's already on your system, so no extra versions of those libraries have to be installed.

2: The app could be made to ship with its own copies of those libraries.

Every AppImage app you install that uses the second option will have its own separate copies of those libraries. This is more bloated than Flatpak.

But if they all use the first option, it's actually less bloated than Flatpak.

@mtjcreative Yes - basically, if the version of the library that the app was developed with happens to be incompatible in any way with the version you have installed on your system, everything will break. Shipping your own copies of the libraries prevents this.

There's technically no reason that different revisions of essential libraries like glibc couldn't all just be compatible with each other. But, sadly, this isn't always the case, and glibc, gtk, etc. devs do sometimes break compatibility.