@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 The final thing that's worth mentioning is that Flatpaks are always "sandboxed", whereas AppImages *can* be sandboxed, or they can be native.

The sandboxing stuff is slow, and I would argue, is completely unnecessary bloat for average desktop use.

The AppImage wiki has an example where a (sandboxed) Flatpak of LibreOffice took 7 seconds to start, whereas an (unsandboxed) AppImage of LibreOffice took 3 seconds.

(It also mentioned that the Snap of LibreOffice took 13 seconds lol)