Traditional Linux packages are tied to a specific distribution and version. Install a .deb on Arch Linux or a .rpm on Debian and it will not work. This creates a real problem for application developers who want to reach all Linux users without building and maintaining separate packages for each distribution.

Snap, Flatpak, and AppImage are three different answers to that problem. Each works by bundling an application with enough of its own dependencies to run anywhere. But the similarities end there. The three differ in centralisation, sandboxing, update behaviour, disk usage, and desktop integration.

The problem they all solve

On a traditional package-managed system:

• Package formats differ between distributions (.deb vs .rpm vs .pkg.tar.zst)
• Library versions differ: what works on Ubuntu 22.04 may not work on Debian 12
• Distribution repository processes are slow; developers cannot ship updates the day they release them
• Users on older LTS releases cannot get new software versions without adding third-party repos

Universal packages solve this by making the application distribution-independent. The application author builds once and ships a single artefact that works on any distribution with the appropriate runtime.

Flatpak

Flatpak is a framework for distributing desktop applications on Linux, developed by Red Hat and the GNOME community. Applications run inside a sandbox with limited access to the host system, using a set of shared runtime libraries rather than bundling everything individually.

How Flatpak works

Each Flatpak application declares:

• Which runtime it requires (e.g., org.gnome.Platform//47 or org.kde.Platform//6.7)
• Which additional extensions and libraries it needs beyond the runtime

The runtime is installed once and shared by all applications that use it. Multiple versions of a runtime can coexist.

Flathub

Flathub (flathub.org) is the primary Flatpak repository, hosting over 2,000 applications. It is not the only source — anyone can host a Flatpak repository — but it covers the vast majority of desktop applications available as Flatpaks.

Using Flatpak

# Install Flatpak
sudo apt install flatpak            # Debian/Ubuntu
sudo dnf install flatpak            # Fedora (usually pre-installed)
sudo pacman -S flatpak              # Arch

# Add Flathub as a source
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

# Install an application
flatpak install flathub org.gimp.GIMP
flatpak install flathub com.spotify.Client
flatpak install flathub org.videolan.VLC

# Run a Flatpak application
flatpak run org.gimp.GIMP

# List installed Flatpak applications
flatpak list
flatpak list --app                  # applications only (not runtimes)

# Update all Flatpak applications
flatpak update

# Update a specific application
flatpak update org.gimp.GIMP

# Remove an application
flatpak uninstall org.gimp.GIMP

# Remove an application and clean up unused runtimes
flatpak uninstall --delete-data org.gimp.GIMP
flatpak uninstall --unused          # remove unused runtimes

# Search for applications
flatpak search gimp

# Show application information
flatpak info org.gimp.GIMP

# List configured remote sources
flatpak remotes

Flatpak sandboxing and permissions

Flatpak applications run in a sandbox with limited host access by default. Permissions are declared by the application and can be inspected and overridden:

# See the permissions an application has requested
flatpak info --show-permissions org.gimp.GIMP

# Override a permission (grant file system access as an example)
flatpak override --user --filesystem=home org.gimp.GIMP

# Revoke a permission
flatpak override --user --nofilesystem=home org.gimp.GIMP

# Install Flatseal (GUI for managing Flatpak permissions)
flatpak install flathub com.github.tchx84.Flatseal

Flatpak directories

~/.var/app/                         # per-user app data
/var/lib/flatpak/app/               # system-wide installed apps
/var/lib/flatpak/runtime/           # shared runtimes
~/.local/share/flatpak/             # per-user installations

Snap

Snap is Canonical’s universal package format, developed primarily for Ubuntu but available on other distributions. Unlike Flatpak’s shared runtimes, Snaps bundle all their dependencies individually, making them more self-contained but also larger.

How Snap works

A Snap is a compressed SquashFS filesystem image. When installed, it is mounted read-only at /snap/packagename/. The snap runtime creates a confined environment using AppArmor, seccomp, and Linux namespaces.

Snaps update automatically in the background by default, typically once a day. This is either a convenience or a problem depending on whether you want control over when your software changes.

The Snap Store

Unlike Flatpak, Snaps are centralised: all packages go through Canonical’s Snap Store. There is no way to set up a competing Snap repository (the snapd client only talks to the official store by default). This gives Canonical more control over the ecosystem and enables features like automatic updates and delta downloads, but is a point of contention in the Linux community.

Using Snap

# Snap is pre-installed on Ubuntu
# On other distributions:
sudo apt install snapd              # Debian
sudo dnf install snapd              # Fedora
sudo pacman -S snapd                # Arch (from AUR)

# Install an application
sudo snap install vlc
sudo snap install spotify
sudo snap install code --classic    # --classic for apps needing broader access

# List installed snaps
snap list

# Update all snaps
sudo snap refresh

# Update a specific snap
sudo snap refresh vlc

# Remove a snap
sudo snap remove vlc

# Search the snap store
snap find "video player"

# Show snap information
snap info vlc

# See snap connections (interface permissions)
snap connections vlc

# Connect a snap interface manually
sudo snap connect some-snap:camera

# See recent snap refresh history
snap changes

Snap confinement levels

Snaps have three confinement levels:

• strict: fully sandboxed with explicit interfaces required for any system access. Most snaps use this.
• classic: behaves like a traditional application with no sandboxing. Used for developer tools (e.g., editors, compilers) that need broad system access. Requires --classic flag during install.
• devmode: developer mode for building snaps; not used for distribution.

# See confinement level of installed snaps
snap list --all | grep -E 'Name|classic|strict'
snap info some-snap | grep confinement

Snap directories

/snap/                              # mounted snap filesystems (read-only)
/var/snap/                          # snap data and state
~/snap/                             # per-user snap data
/etc/apt/sources.list.d/snapd.list  # if installed via apt

AppImage

AppImage is the simplest of the three formats: a single self-contained executable file that requires no installation, no root privileges, and no package manager. Download it, make it executable, and run it.

How AppImage works

An AppImage is an ISO 9660 filesystem image with a small ELF header that executes when you run the file. Inside is the application and all its dependencies. At runtime, the AppImage mounts itself as a filesystem in a temporary directory (using FUSE) and runs the application from there.

Nothing is installed to the system. Nothing is added to the package database. The file is entirely self-contained.

Using AppImages

# Download an AppImage (example: Inkscape)
wget https://inkscape.org/gallery/item/29999/Inkscape-091e20e-x86_64.AppImage

# Make it executable
chmod +x Inkscape-091e20e-x86_64.AppImage

# Run it
./Inkscape-091e20e-x86_64.AppImage

# Run it from anywhere (move to a convenient location)
mv Inkscape-091e20e-x86_64.AppImage ~/Applications/inkscape.AppImage

# Extract the contents (without running)
./inkscape.AppImage --appimage-extract

# Get help / version info
./inkscape.AppImage --appimage-help

AppImages have no automatic update mechanism by default. Some AppImages implement their own update checking using the AppImageUpdate tool:

# Install AppImageUpdate
wget https://github.com/AppImage/AppImageUpdate/releases/latest/download/AppImageUpdate-x86_64.AppImage
chmod +x AppImageUpdate-x86_64.AppImage

# Update a specific AppImage
./AppImageUpdate-x86_64.AppImage /path/to/app.AppImage

AppImage integration with the desktop

AppImages do not create desktop menu entries by default. Two tools handle this:

# AppImageLauncher: intercepts AppImage execution and integrates them
# Install from https://github.com/TheAssassin/AppImageLauncher

# After installing AppImageLauncher, running any AppImage asks
# whether to integrate it with the system or run it without integration

# Alternatively, manually create a .desktop entry
cat > ~/.local/share/applications/myapp.desktop << 'EOF'
[Desktop Entry]
Name=My App
Exec=/home/user/Applications/myapp.AppImage
Type=Application
Categories=Utility;
EOF

Comparison

Feature	Flatpak	Snap	AppImage
Sandboxing	Yes (Bubblewrap + portals)	Yes (AppArmor + seccomp)	No
Auto-updates	No (manual flatpak update)	Yes (background, daily)	No (opt-in per app)
Central store	No (Flathub is primary, not exclusive)	Yes (Snap Store only)	No (download from project site)
Shared runtimes	Yes (GNOME, KDE, etc.)	No (all bundled per snap)	No
Root required	No (user installs possible)	Yes (snapd is a system daemon)	No
Desktop integration	Excellent	Good	Manual setup required
Disk usage	Moderate (shared runtimes)	Higher (all deps bundled)	Highest per-file (but uninstalled = gone)
Availability on non-Ubuntu	Excellent	Limited (snapd required)	Universal
Good for	Desktop apps, all distros	Ubuntu apps, CLI tools	Portable one-off use, testing

Which to use

Use Flatpak for desktop applications on non-Ubuntu distributions, and as the default for most application installs on any distribution. The shared runtime model is more efficient, the sandboxing is strong, and Flathub has the widest selection of GUI applications. If a native package is not available or out of date, Flatpak is usually the right next choice.

Use Snap on Ubuntu when you want automatic updates or when the application you need is only available as a Snap. For CLI developer tools (code, node, kubectl, aws), Snap has good coverage and classic confinement makes it work well. On non-Ubuntu systems, Snap adds more complexity than it is worth for most use cases.

Use AppImage when you need to run an application on a machine where you do not have root access, when you want to test a new version without installing it, or when you need a specific version of an application without disrupting your system’s package state. AppImage’s zero-installation requirement makes it ideal for portable tools and one-off testing.

Native packages vs universal formats

When a native package (.deb, .rpm, .pkg.tar.zst) is available and up to date, prefer it. Native packages are smaller, integrate better with the system, and are managed by the same tools you use for everything else. Universal formats are the right fallback when:

• The software is not in your distribution’s repositories
• The repository version is too old (common on LTS releases)
• You need a specific version the distro does not offer
• You want the application to work the same on multiple different machines

All three formats are tools, not replacements for the distribution package manager. Use them where they help, not by default.

Frequently Asked Questions

What is the difference between Snap, Flatpak, and AppImage?

All three are universal Linux package formats that work across distributions. Snap, created by Canonical, is centralised around the Snap Store and updates automatically. Flatpak is decentralised — Flathub is the main source but anyone can host a Flatpak repository — and integrates well with desktop environments like GNOME and KDE. AppImage is the simplest: a single executable file that requires no installation and runs on any distribution. Each trades off convenience, sandboxing, disk space, and update automation differently.

Is Flatpak better than Snap?

Flatpak and Snap serve similar purposes but have different design philosophies. Flatpak is decentralised, open, and more widely supported outside of Ubuntu. Snap is centralised through Canonical

Do Flatpak apps work on all Linux distributions?

Yes. Flatpak applications are distribution-independent. They bundle their runtime dependencies and run in a sandboxed environment, so the same Flatpak package works on Fedora, Debian, Ubuntu, Arch, openSUSE, and any other distribution that has the Flatpak runtime installed. This is the main appeal of Flatpak: developers build once and users install on any distribution.

Are AppImages safe to use?

AppImages are as safe as the source you download them from. Unlike Flatpak and Snap, AppImages have no central verification or sandboxing by default. An AppImage is an executable file, and running an AppImage from an untrusted source is the same risk as running any unknown executable. Download AppImages only from the official website of the software you want. Some projects sign their AppImages with GPG and publish checksums — verify these when available.

Do Snap and Flatpak apps use more disk space?

Yes, both use more disk space than native packages, because they bundle their dependencies separately from the system. Snap applications each include their own copy of required libraries. Flatpak is slightly more efficient because applications can share runtimes (a common base such as the GNOME or KDE runtime), but you still have multiple runtimes installed. The trade-off is distribution independence at the cost of storage. On a modern system with hundreds of gigabytes of storage, this is rarely a practical concern.