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?

5 Answers 5


Here is a long tabular comparison of AppImage vs. Snap vs. Flatpak features. It is from the AppImage Wiki on GitHub:

Note that this comparison is mainly from the perspective of AppImage, although it tries to represent each project fairly.


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 ❌ No ✅ Yes [1] ❌ No
Package kernels ❌ No ✅ Yes [1] ❌ 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 ❌ No (Community project) ✅ Yes (Canonical) ✅ Yes (Endless, Red Hat)


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


AppImage Download from site, then drag-and-drop a single file in the file manager to desired installation location. drag-and-drop 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] ❌ No (Limiting application access's by design)
Can be used with different sandboxes ✅ Yes (e.g. Firejail [1], AppArmor [2], Bubblewrap) ❌ No (is tightly coupled to AppArmor) ❌ No (is tightly coupled to Bubblewrap)

Application Installation / Execution

Feature AppImage Snap Flatpak
Can run without installation ✅ Yes (after setting the executable bit) ❌ No (needs to be installed by snapd) ❌ 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 ❌ 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) ❌ No (.snap - requires snapd to be installed and the system must be online if additional snaps are required) ❌ 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 ❌ 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 ❌ No (one dominant app store) [1] ✅ Yes
Individual App Repositories ❌ No (not stored in repositories) ❌ 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 ❌ No
Runs on OpenSUSE out-of-the-box ✅ Yes ❌ No tbc
Runs on Fedora out-of-the-box ✅ Yes ❌ No ✅ Yes
Runs on Debian out-of-the-box ✅ Yes ❌ No tbc
Runs on CentOS out-of-the-box ✅ Yes ❌ 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) ❌ No (a Canonical initiative) ✅ Yes (a community project)
Not linked to any dominant company’s business case ✅ Yes ❌ No (central to Canonical’s business) ❌ No
Made to decrease distributions’ influence on the desktop Linux ecosystem as central gatekeepers ✅ Yes ❌ 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) ❌ No (effectively placing another distribution's base snap over the underlying distribution) ❌ 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 ❌ 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) ❌ No [Does not take platform snaps into account [1]] 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 ❌ No (but interested in it once the format is stabilized) ✅ Yes (Created by the Snap format TOB[1]) ❌ 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 ❌ No ✅ Yes
Developed since 2004 (then called klik) 2010 (predecessor called Click Packages) 2013 (predecessors called Glick Glick2, and xdg-app)
  • 84
    I think it's worth pointing out that this chart is built from an AppImage perspective. Meaning, the default feature set is AppImage's feature set, and the others are compared to its features. That gives a biased edge to AppImage. It's also somewhat out of date. For instance, Snap added theme support this fall.
    – Dan
    Apr 16, 2018 at 15:16
  • 18
    I'm not sure how you can say that @Kurt. Take a look at the "Objectives" section, as an example. It shows AppImage's objectives exclusively, as if none of the other projects have any objectives. As if only the objectives that AppImage has matter.
    – Dan
    May 3, 2018 at 18:16
  • 11
    I do get your point - I could edit the wiki. However, your answer is a giant image that will presumably stay as-is in perpetuity, even as the wiki changes. I think the bias is worth mention in context to your answer for future Ask Ubuntu readers.
    – Dan
    Jul 6, 2018 at 19:14
  • 3
    @Dan: I edited the answer on July 4th to insert an updated version of the screenshot from the website (exactly in order to include some modifications which happened to the wiki). Where is the problem for you in editing the original Wiki, creating a new screenshot and then suggesting a modification of this answer with the new screenshot? Jul 7, 2018 at 10:11
  • 13
    What's missing here is the fundamental reason why Flatpaks and Snaps exist, even though AppImage existed long before. With AppImages, it's up to the developer to make sure apps work under all conditions. With Flatpaks (and Snaps too, I believe), there are underlying runtimes that mirror the state of the developer's machine, ensuring that the app works on distros with different setups.
    – Tin Man
    May 4, 2019 at 19:22

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.

  • 3
    Solus has announced support for flatpak in Jan 2017
    – Anthon
    May 28, 2017 at 6:40
  • 17
    They all should have just built upon appimage. Instead of re-inventing the same ideology and introducing fragmentation and confusions. Also note that since these portable packages have all the libraries, they will be considerably heavier in size compared to an app using shared libraries installed via apt or .deb. If you must know which is more popular, flatpak is currently beating snaps. Jun 5, 2017 at 5:22
  • 5
    @answerSeeker: your comment about the portable packages being "considerably heavier in size compared to an app using shared libraries installed via apt or .deb" isn't necessarily backed up by the real life facts. AppImages and Snaps are compressed into SquashFS images (not true for Flatpak). They are never extracted onto disk, not even during run-time. AppImages, when running, self-mount themselves onto a temporarily created mountpoint in /tmp/.mount_<random-chars> and run from there -- still compressed! See the numbers for the LibreOffice example in screenshot of my answer below... Feb 23, 2018 at 15:01
  • 3
    @PabloBianchi: newer AppImages (of the more recent 'type 2' variety) can have a builtin update mechanism. This downloads a binary delta diff from the original AppImage location, saving in download size and time, once a new version is available and after the user indicated s/he wanted it. The tools appimageupdatetool (CLI) and AppImageUpdate-Qt (GUI) help with this. Feb 23, 2018 at 15:06
  • 4
    flatpack was actually introduced a few months before snap, for those wondering who invented what when. It appears they were invented simultaneously for different reasons. Flatpack was not a new technology, my team implemented something similar in the 00's using the same technique (namespaces) but I couldn't get management to open source it so that company died. Namespaces exist everywhere, snap with its dependency on AppArmor is harder to move to other distributions.
    – eric.green
    Dec 11, 2020 at 17:55

do not forgot the main thing, is it Open source ?


Open source Client ✅ Yes
Open source Server ✅ Yes


Open source Client ✅ Yes
Open source Server ❌ No


Open source Client ✅ Yes
Open source Server ✅ Yes

  • The snap store is not open-source, there were some attempted implementations but no current working ones. Please see forum.snapcraft.io/t/external-repositories/1760 for the very lengthy discussion on this general topic regarding the server side of desktop snap apps.
    – Ads20000
    Jan 28, 2021 at 22:34

I have found an interesting performance (CPU+Memory) comparison for these packaging systems.



LibreOffice enter image description here


enter image description here

Source: https://verummeum.com/portable-package-formats/

  • 21
    This would be much easier to read if the scales were uniform. Mar 9, 2021 at 16:50
  • Unluckily in my source only these plctures were available.
    – pktiuk
    Mar 9, 2021 at 22:40
  • 4
    Also would be good to add a conclusion.
    – Chris
    Dec 9, 2021 at 11:56

If you have several flatpaks running, the filesystem does not work properly. For example, if I have Openscad and Flashprint open, I can write to disk(s) from Openscad, but not from Flashprint. In Snap there seems to be no problemos.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .