Flatpak, Snap, and AppImage

APT and dpkg, DNF and RPM, and Pacman all share a limitation: packages come from that specific distribution's repositories, built against that distribution's library versions. These three formats sidestep that by bundling a package with everything it needs to run, at the cost of duplicating shared libraries that a native package would simply depend on.

Why these exist

• Newer software than a distro repo ships - a stable distro release freezes package versions for a long time; an app maintainer publishing directly to Flathub or the Snap Store can ship updates immediately instead of waiting for the next distro release cycle.
• One package, every distro - a developer builds and publishes once, rather than maintaining separate .deb, .rpm, and Arch packages.
• Sandboxing - Flatpak and Snap run applications with restricted access to the rest of the system by default (no filesystem access outside chosen directories, for example), unlike a traditionally installed package.

Flatpak

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install flathub org.gimp.GIMP
flatpak run org.gimp.GIMP
flatpak update
flatpak list
flatpak uninstall org.gimp.GIMP

Flathub is the dominant Flatpak repository, comparable to what Docker Hub is for container images. Flatpak apps are identified by a reverse-DNS style ID (org.gimp.GIMP) rather than a short package name. Permissions (filesystem access, network, device access) can be inspected and adjusted with flatpak override or the Flatseal GUI tool.

Snap

sudo snap install spotify
sudo snap list
sudo snap refresh          # update all installed snaps
sudo snap remove spotify

Snap is developed by Canonical and preinstalled on Ubuntu; snapd, the background service that manages snaps, needs to be installed manually on other distributions. Snaps update automatically in the background by default (snap refresh normally isn't something you need to run yourself), which is convenient but worth knowing if you need a specific version pinned.

AppImage

chmod +x SomeApp.AppImage
./SomeApp.AppImage

AppImage is the simplest of the three: a single executable file containing the application and its dependencies, requiring no installation step, no daemon, and no root access to run at all - just mark it executable and run it directly. There's no built-in update mechanism or central repository; updates mean downloading a new AppImage file yourself (some apps embed an updater, most don't).

In practice, running one also requires FUSE (specifically libfuse2) to be installed on the host, since that's what mounts the AppImage's embedded filesystem at launch - current Ubuntu, Debian, and Fedora releases no longer ship it by default, so a first run commonly fails with a dlopen(): error loading libfuse.so.2 error until it's installed (sudo apt install libfuse2, which does need root, ironically). The --appimage-extract flag works around this by unpacking the AppImage to a directory instead of mounting it, if installing FUSE isn't an option.

Comparing the three

The tradeoff

Every one of these formats ships its own copy of shared libraries instead of using the system's - meaning more disk space per application and, particularly for Flatpak and Snap, a noticeably slower first launch while a sandboxed runtime spins up. For software that's already well-packaged and current in your distribution's own repository, the native package (via apt, dnf, or pacman) is usually still the better default - these formats earn their overhead specifically for software that isn't, or where sandboxing itself is a deliberate goal.