What are the differences between snaps, appimage, flatpak and others?
I have been getting this question lately from students and although I have a lot of information to offer, I have not found a source that I can point people to where they can read an update answer (I have found a lot of misinformation and obsolete information). So, some of the questions I have for package formats like snap, appimage, flatpak and others in this evolution of universal packaging systems are:
- Who created the package format?
- What features does it offer?
- What features are unique to it? (That the others do not yet have)
- Who supports it?
- What Distributions use it?
- What focus does the package have? (For Desktop, Clouds, Mobile, etc..)
- Which are more actively developed?
Solution 1:
Here is a long tabular comparison of AppImage vs. Snap vs. Flatpak features. It is from the AppImage Wiki on GitHub:
- https://github.com/AppImage/AppImageKit/wiki/Similar-projects#comparison
Note that this comparison is mainly from the perspective of AppImage, although it tries to represent each project fairly.
General
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Package desktop GUI apps | ✅ Yes | ✅ Yes | ✅ Yes |
| Package terminal CLI tools | ✅ Yes | ✅ Yes | ✅ Yes (with App ID aliases if you edit PATH)[1] |
| Package server processes | ✅ Yes | ✅ Yes | ⚠️ Possible but not main goal [1] |
| Package system services | :x: No | ✅ Yes [1] | :x: No |
| Package kernels | :x: No | ✅ Yes [1] | :x: No |
| Correct Application Theming | ✅ Yes (if done correctly) | ✅ Yes (if the current system theme has been Snapped) [1] | ✅ Yes (if current system theme has been Flatpak'ed) [1] [2] [3] |
| Using libraries and dependencies | From base system or bundled with appimage | From base system, base snap, platform snap (KDE, GNOME, Wine, ..) or bundled with Snap | From Freedesktop, GNOME, KDE main runtimes or bundled with Flatpak |
| Corporate backing | :x: No (Community project) | ✅ Yes (Canonical) | ✅ Yes (Endless, Red Hat) |
Adoption
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Number of applications in main store | 1126 (2020-08-14 [1] history) | +6400 (2020-08-06 [1]) | ~1100 (2020-08-14) |
| Brand-name commercial application vendors using the format | Adobe, IBM, KDAB, Microsoft, Prusa, Ultimaker, ... | Microsoft, Spotify, Slack, JetBrains, Skype, nodesource, ... | Xamarin, Codethink, Igalia, ... |
| Built into third-party application development tools | electron-builder | electron-builder, GNOME Builder | GNOME Builder |
Usability
AppImage
Download from site, then drag-and-drop a single file in the file manager to desired installation location.
Snap
Install via distribution app store (supported out of the box on Ubuntu, Zorin OS, KDE Neon, ..) or via CLI:
$ snap install gimp
Flatpak Install via distribution app store (supported out of the box on Fedora, EndlessOS, ..) or via CLI:
$ flatpak install --user flathub org.gimp.GIMP
Sandboxing / Confinement
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Can run without sandboxing | ✅ Yes (Not required. Optional to the packager.) | ✅ Yes (if snap was built and approved to use 'classic' confinement) [1] [2] | :x: No (Limiting application access's by design) |
| Can be used with different sandboxes | ✅ Yes (e.g. Firejail [1], AppArmor [2], Bubblewrap) | :x: No (is tightly coupled to AppArmor) | :x: No (is tightly coupled to Bubblewrap) |
Application Installation / Execution
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Can run without installation | ✅ Yes (after setting the executable bit) | :x: No (needs to be installed by snapd) | :x: No (needs to be installed by Flatpak client-side tools) |
| Can run without root access | ✅ Yes | ⚠️ Only after installation | ⚠️ Only after installation |
| Run from compressed source and not unpacked | ✅ Yes | ✅ Yes | :x: No |
| Application authors can place downloadable file next to .exe (Windows) and .dmg (macOS) which users can install on offline systems | ✅ Yes (.appimage - contains all that is needed to run the application on an offline system) | :x: No (.snap - requires snapd to be installed and the system must be online if additional snaps are required) | :x: No (.flatpakref files require Internet, .flatpak bundles require a runtime to be installed) |
| Allows application authors to self-host application with no functionality loss | ✅ Yes | :x: No | ✅ Yes [1] |
| Suitable/optimized for air-gapped (offline) machines (the kind Ed Snowden uses) | ✅ Yes | ✅ Yes (You can side-load apps and updates offline) | ✅ Yes (P2P support allows offline installs and updates) |
| Can store and run applications from non-standard locations such as network shares, CD-ROM, etc. | ✅ Yes | tbd | ✅ Yes (requires configuration) [1] |
Application Distribution
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Central Repo / Directory | AppImageHub | Snap Store | FlatHub |
| Fully decentralized without central gatekeepers | ✅ Yes | :x: No (one dominant app store) [1] | ✅ Yes |
| Individual App Repositories | :x: No (not stored in repositories) | :x: No (you can only have one repo per device) | ✅ Yes |
| Can have multiple versions in parallel (including historical ones) | ✅ Yes (unlimited number of arbitrary versions) | ✅ Yes (one per channel) | ✅ Yes (any version available in OSTree can be installed in parallel) |
| Once the application is installed, it still can be easily copied to another machine (e.g., share with a friend locally) | ✅ Yes (one app=one file; there is no “installation” so the app is in the same form at all times) | ✅ Yes (but also need to copy snaps it depends on) | ✅ Yes (you can use flatpak create-usb to copy to USB drive) |
Application Updates
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Update mechanism | AppImageUpdate | From Repo | From Repo |
| Binary delta updates | ✅ Yes (using zsync with no need to generate deltas in advance) | ✅ Yes (Only if using a private server-side service that needs to generate the deltas) | ✅ Yes (using OSTree to provide atomic updates) |
| Applications can be self-updating | ✅ Yes (using embedded information) | ✅ Yes | ✅ Yes |
Linux Distribution Support
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Earliest Ubuntu Supported | Ubuntu 10.04 | Ubuntu 14.04 | Ubuntu 16.04 |
| Earliest OpenSUSE Supported | OpenSUSE 11.3 | Leap 42.2 | Leap 42.1 |
| Earliest Fedora Supported | Fedora 12 | Fedora 24 | Fedora 23 |
| Earliest Debian Supported | Debian 6 | Debian 9 | Debian 9 |
| Earliest CentOS Supported | CentOS 6 | CentOS 7.6 | CentOS 7 |
| Runs on Ubuntu out-of-the-box | ✅ Yes | ✅ Yes | :x: No |
| Runs on OpenSUSE out-of-the-box | ✅ Yes | :x: No | tbc |
| Runs on Fedora out-of-the-box | ✅ Yes | :x: No | ✅ Yes |
| Runs on Debian out-of-the-box | ✅ Yes | :x: No | tbc |
| Runs on CentOS out-of-the-box | ✅ Yes | :x: No | ✅ Yes |
| Live systems (e.g., Live ISO, Live USB, Live CD, Live network boot) | ✅ Full | ⚠️ Partial (starting with 18.04, but it is limited by a kernel limitation and "a pain to work with, we spend almost zero time with that" according to a Canonical developer) | ⚠️ Partial (Session must be restarted for exports to be picked up) |
| Can run on Chrome OS (Crostini) | ✅ Yes (Chrome OS 73) | ✅ Yes (Chrome OS 73) | ✅ Yes |
Objectives and governance
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Independent from any particular distribution maker | ✅ Yes (a community project) | :x: No (a Canonical initiative) | ✅ Yes (a community project) |
| Not linked to any dominant company’s business case | ✅ Yes | :x: No (central to Canonical’s business) | :x: No |
| Made to decrease distributions’ influence on the desktop Linux ecosystem as central gatekeepers | ✅ Yes | :x: No | ✅ Yes (Everyone can host his / her own repo) |
| Made to empower application developers and end users | ✅ Yes | ✅ Yes [1] | ✅ Yes [1] |
| Working to unify the Desktop Linux Platform rather than continuing to split the user base into different distribution ecosystems | ✅ Yes (by pointing out the core issues that need to be solved together) | :x: No (effectively placing another distribution's base snap over the underlying distribution) | :x: No (effectively placing a Yocto distribution over whatever underlying distribution) |
Application Size
| Feature | AppImage | Snap | Flatpak | |
|---|---|---|---|---|
| Application storage on disk remains compressed at all times | ✅ yes | ✅ yes | :x: No (server-side is compressed, client-side is not) [1] | |
| Applications use much less disk space than "traditionally installed" ones | ✅ yes | ✅ yes | tbd | |
| Example: LibreOffice download size (source) | ~248 MByte | 463 MByte [July 2020 update] | 543 MByte | |
| Before downloading, know exactly the size to be downloaded and stored on disk | ✅ Yes (One app = one file) | :x: No [Does not take platform snaps into account [1]] | :x: Can only estimate worst case due to de-duplication |
Execution speed
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| LibreOffice start time (source) | 3 seconds | 13 seconds | 7 seconds |
Package Format
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| File format is standardized through an official standards body | :x: No (but interested in it once the format is stabilized) | ✅ Yes (Created by the Snap format TOB[1]) | :x: No (although experimental OCI support exists) |
| Conceptually inspired by | macOS .app inside .dmg (tracing back to NeXT); Rox AppDir | Click (Ubuntu Touch packages) | klik (former name of AppImage) |
Project Codebase
| Feature | AppImage | Snap | Flatpak |
|---|---|---|---|
| Contributors do not need to sign a CLA | ✅ Yes | :x: No | ✅ Yes |
| Developed since | 2004 (then called klik) | 2010 (predecessor called Click Packages) | 2013 (predecessors called Glick Glick2, and xdg-app) |
Solution 2:
Snaps were created by Canonical for Ubuntu. The main advantages of snaps are:
- Independence on dependencies - all libraries and dependencies are included in the package. This also allows to have more versions of the same program.
- Sandboxing - snaps are using modified AppArmor to sandbox the applications
- Delta updates - snaps should also allow delta updates
The main drawback of snaps is that software can only use libraries included in its package. This is a potential security risk as the author of the package needs to keep all libraries patched and updated.
Snaps can currently run in Ubuntu, Arch Linux, Fedora, Linux Mint, CentOS, and Gentoo. They are also used in Ubuntu Touch. They are designed for desktops, servers, phones, IoT, and routers.
Flatpak has the same advantages as snaps. However, it uses Namespaces instead of AppArmour for sandboxing. The main difference is that Flatpaks can both use libraries included in the package and shared libraries from another Flatpak.
The developer of Flatpak is the Red Hat employee Alexander Larsson. Flatpak software is currently available in Arch Linux, Debian, Fedora, Mageia, Solus and Ubuntu. It is focused on desktops only.
AppImages are developed by Simon Peter. As in snaps or Flatpak, the package includes all libraries necessary to run the program. AppImage programs are not sandboxed and they don't require root rights to run. According to website of the project, AppImages should run on Arch Linux, Centos, Debian, Fedora, OpenSUSE, Red Hat Linux and Ubuntu.
Solution 3:
I have found an interesting performance (CPU+Memory) comparison for these packaging systems.
VLC
LibreOffice
Gimp
Source: https://verummeum.com/portable-package-formats/
Solution 4:
do not forgot the main thing, is it Open source ?
AppImage
Open source Client ✅ Yes
Open source Server ✅ Yes
Snap
Open source Client ✅ Yes
Open source Server ❌ No
Flatpak
Open source Client ✅ Yes
Open source Server ✅ Yes