We explained what Flatpak, Snap, and AppImage are in the article How Do They Stack? published over 2 years ago and while the technologies have improved a lot since that time, I’m evaluating them from the perspective of a software developer.
Sandboxing / Confinement
You can run AppImage without sandboxing as well as use it with different sandboxes e.g. AppArmor and Firejail.
Snap can run without sandboxing but you cannot use it with different sandboxes as it is tightly coupled to AppArmor.
Flatpak can neither run without sandboxing nor can it be used with different sandboxes other than Bubblewrap.
Installation / Execution
One can run an AppImage after setting the executable without root access, without decompressing it, and on an offline system.
Snap needs to be installed by snapd, cannot run without root access until after it is installed nor can its downloadable file be placed next to .exe and .dmg which users can install on offline systems, but it can run from an uncompressed source.
Flatpak needs to be installed by a Flatpak client-side tool, cannot run without root access until after installation, cannot run from an uncompressed source. Also, .flatpakref files require Internet and .flatpak bundles require a run-time to be installed.
AppImage can store and run applications from non-standard locations such as CD-ROM and network shares. Flatpak can do the same after some configuration, while Snap currently can’t.
In this section, AppImage takes the cake because its applications are more flexible.
Application Distribution & Updates
The central repository for Flatpak and Snap is FlatHub, and Snap Store respectively. Users can download AppImages from AppImageHub which is a cataloguing platform for software available as AppImage bundles.
Unlike AppImage and FlatPak, however, the Snap Store is the only dominant app store with one repo per device. Whether that is a good or bad thing is for you to decide.
Apps packaged using all 3 methods can have multiple versions running in parallel and can be easily copied to another machine. However, they have their unique implementations.
All 3 support binary delta updates but only AppImage apps can be self-updating as Snap apps need snapd to be installed and Flatpak apps need Flatpak to be installed.
Summarily
AppImages and Snap remain compressed at all times (Flatpak is compressed only on the server-side) and are typically smaller in size than Flatpak apps. AppImage is also independent of any distro maker and aims to unify Linux platform ecosystems.
Snap is owned by Canonical and places its base snap over the underlying distro, while Flatpak is a Red Hat initiative that places a Yocto distro over the underlying distro. Also, unlike with Snap where developers need to pay to Canonical, AppImage and Flatpak are free to use.
From where I stand, AppImages are the ideal packaging method to use because it is the most convenient for both developers and end users. However, it is possible for them to coexist especially when there are cases developers will prefer to use one of the other. Tell us what you think in the comments section below.
My research for this article was greatly influenced by Similar projects and the Reddit threads here and here. Feel free to check them out for more insight.
There is another option: static builds, like portable apps in Windows. You download an app archive, unpack it (say, to /opt) and launch the app. I use DeaDBeeF this way.
snaps are slow as balls. Havent used appimage yet but im not sure why I should since they are compressed like snaps and will be prone to extremely slow start times as well. Flatpaks are fast as shit, just do the simple spotify test, easily loads 10x as fast on flatpak then it does snap. Hate snaps and I hate how Ubuntu uses it for shit like the calculator, like wtf? Calc takes 3 seconds to load lmfao. terrible.
AppImage has an extract option. Also I don’t think it’s slow, the startup speed is reasonable.
I did an experiment where I tried to use only those formats to install my software with Appimage being first my choice. At least, where possible. Anyway, the system maintained a higher level of performance when compared to one where the software was installed with traditional methods. I started with a fresh install (KDE Neon) and I saw almost no degradation in system performance after installing a great deal software.
Appimages could not be easier, or more convenient. I am starting to really like them. It appears the format is starting to gain serious momentum now. In fact, that looks to be true of all three. Appimage could be a solution to getting more cross-platform supporting Linux. As it stands, cross-platform often just means Windows and MacOS though not always.
One small correction regarding AppImageHub: AppImageHub is not a “central repository”. It rather is a catalogue of software available in the shape of AppImage bundles. The download has to take place from the respective locations, which the catalogue may or may not point to….
Thanks for the correction Kurt, I’ve applied it.