233

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?
Diogo Gomes
  • 560
Luis Alvarado
  • 211,503

5 Answers5

188

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.

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 ❌ 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)

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.

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 without unpacking ✅ 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)
Independent from domination by any 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 can avoid signing CLAs ✅ Yes ❌ No ✅ Yes
Developed since 2004 (then called klik) 2010 (predecessor called Click Packages) 2013 (predecessors called Glick Glick2, and xdg-app)
Daniel T
  • 4,594
Kurt Pfeifle
  • 4,495
  • 85
    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 '18 at 15:16
  • 1
    @Dan: If you are in the know about Snap's added them support -- why don't you then simply edit into the chart? Also, if you know about other features which are in Snap and/or Flatpak: feel invited to amend the chart with the respective items in the AppImage wiki... – Kurt Pfeifle Apr 16 '18 at 16:31
  • 1
    Also, dear @Dan: I do not agree with you that "the default feature set is AppImage's feature set, and the others are compared to its features". How else/otherwise would you you explain the entries for item "Individual App repositories"? – Kurt Pfeifle Apr 16 '18 at 16:35
  • 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 03 '18 at 18:16
  • 1
    @Dan: Why then don't you submits edits to the original table which show the "other projects' objectives"? It's a Wiki, you know... – Kurt Pfeifle Jul 04 '18 at 09:43
  • 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 06 '18 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? – Kurt Pfeifle Jul 07 '18 at 10:11
  • // , Wow, AppImage looks great – Nathan Basanese Nov 22 '18 at 00:33
  • 16
    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 04 '19 at 19:22
  • @TinMan: I'm sure you are smart enough to re-phrase that statement/observation into a form which makes it fit into the table as an additional entry point. Put it into the original wiki, and I'll make sure to include the updated screenshot with your contribution into my answer. – Kurt Pfeifle May 04 '19 at 19:30
  • Under "Application Size" you have a couple of ticks next to "Applications use much less disk space". I only have anecdotal evidence, but in my experience this is totally wrong. GIMP snap is 229MB, GIMP (traditional) is 4MB. Inkscape is 182MB vs 79MB. – aidan May 06 '19 at 04:59
  • @aidan: (1) I think you are definitely wrong with GIMP (traditional). Maybe the mere executable of GIMP is only 4 MByte. But you have to count all of the files which are included into the GIMP package, plus all of the packages which GIMP directly requires (like 'gimp-data', 'libgimp-2.0' etc.) which contains quite a lot of library files as well. See for example here: https://packages.debian.org/de/jessie/gimp and here: https://packages.debian.org/de/jessie/amd64/gimp/filelist. – Kurt Pfeifle May 06 '19 at 14:05
  • @aidan: (2) While the first link has a table (scroll down completely) which confirms your number of 4 MByte for the GIMP package, it also says what this number is for: the packaged, compressed byte size. Right next to it is the number for 'Size (installed)' which already gives 15,2 MByte. Add the respective numbers for 'gimp-data' and 'libgimp-2.0', and you already consume 63 MByte of disk space. Plus, you'll need to put more packages into place in order to get a working GIMP installation.... – Kurt Pfeifle May 06 '19 at 14:12
  • @KurtPfeifle Ok, so my numbers were a bit off, but how can a program packaged up with all its dependencies be smaller than the same program sharing dependencies with everything else on the host OS? – aidan May 08 '19 at 00:00
  • @aidan: The secret is that it is compressed on disk and it *remains* compressed on disk while it runs in RAM. 'Classical' package management systems ship software also compresssed, but only on shipment. The installation process places the files on disk uncompressed, hence taking much more disk space. – Kurt Pfeifle May 08 '19 at 08:37
  • @aidan: Trust me, the numbers in the table are correct (in the sense of "roughly", "approximately" -- not necessarily to the last byte). – Kurt Pfeifle May 08 '19 at 08:38
  • 1
    I think this is a more balanced comparison between the 3: Comparison: Snap vs Flatpak vs AppImage. It mentioned more about the reason behind the design of Snap and Flatpak (which AppImage didn't addressed in the first place). It also mentioned the advantage of AppImage. – Koala Yeung Oct 06 '20 at 01:57
  • there is site tracking total number of snaps here: https://snapstats.org/ – Fuseteam Oct 29 '21 at 16:32
91

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.

K7AAY
  • 17,202
Magma
  • 1,078
  • 3
    Solus has announced support for flatpak in Jan 2017 – Anthon May 28 '17 at 06: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. – answerSeeker Jun 05 '17 at 05:22
  • @magma, considering this answer, do you know how AppImage and Flatpak packages get updated (manually like snap refresh or automátically)? – Pablo Bianchi Jan 27 '18 at 22:35
  • 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... – Kurt Pfeifle Feb 23 '18 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. – Kurt Pfeifle Feb 23 '18 at 15:06
  • I also like the Snap store and the installation statistics it provides for the developer (where your app is being used, which versions are installed on which version of Ubuntu etc etc). – juzzlin Sep 14 '18 at 14:14
  • // , Looks like a case of Not Invented Here. :( – Nathan Basanese Nov 22 '18 at 00:34
  • Linux Mint actually dropped support for Snap and went with flatpak. – ostrokach Jul 01 '20 at 16:11
  • 1
    @Chris, spectre has nothing to do with using shared libraries but running on same CPU. – akostadinov Aug 25 '20 at 13:48
  • 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 '20 at 17:55
  • two corrections: (1) snaps are not currently used in ubuntu touch, (2) there are now base snaps, so snaps can share dependencies, one side effect of this is that snaps can be smaller than traditional installs – Fuseteam Oct 29 '21 at 16:38
  • "why reinvent the wheel?" They don't. It's like saying "GM does cars, why does Toyota reinvent the wheel?" (!pun) I've tried the 3 (for Gimp), and in terms of a) package availability and b) packages info, interactivity, intuitiveness, I see a clear winner: flatpak. snap is not far behind, and appimage is last (it might have some interesting features, but the update process, the "finding", the versioning... not for me). – Déjà vu Jan 28 '22 at 09:11
26

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

Ads20000
  • 1,963
user64103
  • 361
  • 3
  • 3
  • The snap store is not open-source, there were some attempted implementations but no current working ones. Please see https://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 '21 at 22:34
24

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

VLC

VLC

LibreOffice enter image description here

Gimp

enter image description here

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

pktiuk
  • 879
0

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.

Timo Noko
  • 1