Note: Please feel free to contribute to this page if you discover inaccuracies.
An AppImage is basically a self-mounting disk image that contains an application and everything the application needs to run on the target systems.
This page compares various similar systems to AppImage. Of course, each system was built toward its own specific objectives. This page is intended to illustrate the points that were important in the AppImage design, and similarities as well as differences to other systems.
The AppImage format is popular with users due to its simplicity (download one file, run it, done) and with developers (one Linux file that runs on all distributions).
The purpose of this table is not to show that AppImage is "better" than the other solutions. The point is to show that while similar in some aspects, there are still fundamental differences in objectives, scope, and features that justify the co-existence of AppImage with the other solutions.
|Desktop GUI apps||✅ Yes||✅ Yes||✅ Yes|
|Terminal CLI tools||✅ Yes||✅ Yes||✅ Yes (with App ID aliases if you edit PATH)|
|Server processes||✅ Yes||✅ Yes||No (possible but not main goal) |
|Correct Application Theming||✅ Yes (if done correctly)||No (snapd doesn't have full theming integration)  ||✅ Yes (if current system theme has been Flatpak'ed)   |
|Libraries / Dependencies||Base system or bundled with appimage||Base distro snap or with parts/plugins||Freedesktop, GNOME, KDE main runtimes or bundled|
|Corporate backing||Community project not driven by a single company. But AppImages are produced by many large and small companies including IBM, KDAB, Microsoft, Prusa Research, Ultimaker||A single company: Canonical||Multiple companies: Endless, Red Hat, Codethink, Igalia|
Example: Copying an application to USB stick
Drag-and-drop of one single file in the file manager
This is a single click in EndlessOS' version of GNOME Software but can be done via CLI:
$ flatpak remote-modify --collection-id=org.flathub.Stable flathub $ flatpak update $ flatpak create-usb /run/media/me/Flatpak org.gimp.GIMP $ flatpak install --user flathub org.gimp.GIMP
Sandboxing / Confinement
|Can run without sandboxing||✅ Yes||✅ Yes (if snap was built and approved to use 'classic' confinement)  ||No|
|Can be used with different sandboxes||✅ Yes (e.g. Firejail , AppArmor , Bubblewrap)||No (is tightly coupled to AppArmor)||No (is tightly coupled to Bubblewrap)|
Application Installation / Execution
|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||No (yes only after installed)||No (yes after Flatpak tool is installed)|
|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 |
|Suitable/optimized for air-gapped (offline) machines (the kind Ed Snowden uses)||✅ Yes||No||✅ 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) |
|Central Repo / Directory||AppImageHub||Snap Store||FlatHub|
|Fully decentral without central gatekeepers||✅ Yes||No (one dominant app store) ||✅ 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
|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)||No (needs snapd to be installed)||No (needs Flatpak to be installed)|
Linux Distribution Support
|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|
|Runs on Ubuntu out-of-the-box||✅ Yes||✅ Yes||tbc|
|Runs on OpenSUSE out-of-the-box||✅ Yes (once FUSE bug is solved)||tbc||tbc|
|Runs on Fedora out-of-the-box||✅ Yes||tbc||✅ Yes|
|Runs on Debian out-of-the-box||✅ Yes||tbc||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
|Independent from any particular distribution maker||✅ Yes (a community project)||No (a Canonical initiative)||No (a Red Hat initiative)|
|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||No|
|Made to empower application developers and end users||✅ Yes||No (application developers needing special permissions must pay Canonical)||✅ Yes |
|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 storage on disk remains compressed at all times||✅ yes||✅ yes||No (server-side is compressed, client-side is not) |
|Applications use much less disk space than "traditionally installed" ones||✅ yes||✅ yes||tbd|
|Example: LibreOffice download size (source)||✅ ~248 MByte||519 MByte||543 MByte|
|Before downloading, know exactly the size to be downloaded and stored on disk||✅ Yes (One app = one file)||(tbc)||Can only estimate worst case due to de-duplication|
|LibreOffice start time (source)||✅ 3 seconds||7 seconds||13 seconds|
|Contributors do not need to sign a CLA||✅ Yes||No||✅ Yes|
|File format is standardized through an official standards body||No (but interested in it once the format is stabilized)||No||No (although experimental OCI support exists)|
|Conceptually inspired by||macOS .app inside .dmg (tracing back to NeXT); Rox AppDir||klik? (former name of AppImage)||klik (former name of AppImage)|
|Number of available GUI or CLI applications (non-web)||Number listed on AppImageHub:
862 as of 10.05.2019,
687 as of 23.03.2019,
242 as of 22.02.2018,
141 as of 05.11.2017;
more on AppImages Wiki
|~2437 as of 2018.10.06 (only counting x86_64, subtracting 'hello world' test apps)||500 apps on Flathub as of 2019-02-22|
|Brand-name commercial application vendors using the format||Adobe, IBM, KDAB, Microsoft, Prusa, Ultimaker, ...||Microsoft, Spotify, Slack, JetBrains, Skype, nodesource, ...||Xamarin|
|Built into third-party application development tools||electron-builder||electron-builder||GNOME Builder|
|Developed since||2004 (then called klik)||2010 (predecessor called Click Packages)||2013 (predecessors called Glick Glick2, and xdg-app)|
RISC OS, NeXTStep, Mac OS X, macOS, iOS
The closer equivalent to NeXTStep's application bundle format would be an application directory, which according to Wikipedia dates back to RISC OS from 1987; so at the point of this writing more like 30 years ago. Which shows that the concept here is far from "new" and apparently something people have been thinking about for a very long time already.
Conceptually, an AppImage is more like a "
.app inside a self-mounting and self-executing
.dmg", that is an application directory (following the ROX AppDir specification) inside a self-mounting filesystem image.
"Revisiting How We Put Together Linux Systems"
Revisiting How We Put Together Linux Systems (Lennart Poettering)
In this frequently cited post, Lennart outlines the conceptual framework for a new way of distributing software, both in the system and the application layers.
We want an efficient way that allows vendors to package their software (regardless if just an app, or the whole OS) directly for the end user, and know the precise combination of libraries and packages it will operate with.
AppImage, in contrast, has a more concise scope: it is only concerned with (mainly add-on, third-party) applications intended to run on top of various base operating systems. In this regard, the AppImage concept resembles other successful desktop operating systems like Windows and OS X where there is a clear separation between a fixed set of what comes with the base operating system (system layer), and everything else that comes from third parties and runs on top of it (application layer). As of today, this model is still "owning" the desktop by far in terms of market share.
We want to allow end users and administrators to install these packages on their systems, regardless which distribution they have installed on it.
AppImages are also designed to run on top of various distributions, but they do not need to be installed.
We want a unified solution that ultimately can cover updates for full systems, OS containers, end user apps, programming ABIs, and more.
These are ambitious goals which significantly exceed the scope of AppImages. The AppImage format does not try to reinvent the world, but rather provide a simple solution for directly distributing upstream applications to as many end users as possible easily. (Although there is a sister project, SystemImageKit, that adds toward a "unified solution" (covering the system layer) which works today, albeit in a completely different way.
We want our images to be trustable (i.e. signed)
AppImages can be checksummed and signed, although this has not been implemented in AppImageKit so far.
we need to make sure we make distributions relevant again for all use-cases, not just those of highly individualized systems.
AppImage instead takes the distributions as a "black box" and provides a way "around them" for directly distributing applications to end users, rather than waiting for them.
Of course, we are developers of the systemd project. Implementing this scheme is not just a job for the systemd developers. This is a reinvention how distributions work, and hence needs great support from the distributions.
While technically way more sophisticated than AppImage in several ways, it is the "great support from the distributions" that would be required for this to happen which makes it interesting to see whether this will catch on.
Flatpak (renamed from "xdg-app")
GitHub (Alexander Larsson)
There are two main goals with this project. 1. We want to make it possible for 3rd parties to create and distribute applications that works on multiple distributions. 2. We want to run the applications with as little access as possible to the host. (For example user files or network access)
AppImageKit shares (and cares deeply about) #1, and is beginning to consider #2 as the infrastructure provided by the kernel and other parts of the system (like overlayfs, systemd, cgroups, namespaces, kdbus, etc.) fall into place.
Application deployment framework for desktop apps
While the name implies a cross desktop environment solution, current work seems to be mostly focused on GNOME as evidenced by the fact that its homepage seems to be https://wiki.gnome.org/Projects/SandboxedApps.
A runtime provides a well-defined environment that an app can run in. Examples would be "GNOME 3.14" or "KDE 5.6". A runtime can be thought of as a /usr filesystem with fixed contents. When a bundled app gets run, the runtime it needs gets mounted at /usr.
This means that in addition to the base operating system, a rootfs called the "runtime" is required. Unlike AppImages, which bundle all the dependencies that are not part of the base operating system, applications packaged for xdg-app bundle the dependencies that are not part of the Yocto-generated "runtime" rootfs. While this a very clean concept, this seems to be overkill for many scenarios in practice. Runtimes are MB-heavy. As this catches on, multiple runtime versions will be needed for the different runtimes, which will add to the storage requirements. Imagine you want the latest version of Firefox. But that requires a newer GTK runtime than what you currently have... All of this is not helped by the fact that the runtimes, like the applications, are not single files (like AppImages) but everything is spread out into individual files - so forget about easily downloading a file and putting it on a USB stick.
Downloads the individual parts of the apps (each file separately). While this is efficient, it creates the need for, well, not package but file-level management. So with xdg-app, you end up with 2 managers: one package manager in the base operating system and one "ostree manager" provided by xdg-app. In contrast, AppImages are designed to have no dependencies that are not part of the base operating system. So you do not need additional software to download and run them.
https://wiki.gnome.org/Projects/SandboxedApps/Sandbox describes the sandbox. Here is a quick overview of how this (supposedly) works: Essentially the
xdg-app-helper is a runtime that needs to be installed on the host system with elevated rights (e.g., suid - isn't this a bad idea?) that sets up a tmpfs for / and bind-mounts stuff into it (although without an overlayfs so far). All of this is done with CLONE_NEWFS ("unshared namespace") so that other processes on the system don't see this, only the app in question.
In contrast, AppImages are designed not to need root or suid helpers and have no dependencies beside the base operating system. But we can run AppImages inside the same sandbox that is also used by Flatpak: https://github.com/probonopd/AppImageKit/tree/master/sandbox
Also, Firejail has native AppImage support.
As of March 2016, xdg-app does not run on live systems which use tmpfs (like Ubuntu and Fedora Live ISOs). Bummer.
As of February 2018, Flatpak is not installed by default on Ubuntu. It has to be installed manually by the user with
sudo apt install flatpak before it can be utilized.
This is the user experience on a freshly booted
GitHub (Matthias Klumpp)
Limba provides developers with a way to easily create software bundles for their applications which run on multiple Linux distributions. It provides atomic upgrades of software, simultaneous installation of multiple software versions and a simple way to obtain and upgrade software. Limba is based on ideas of Glick2 and Listaller, and uses modern Linux kernel features to allow applications to share libraries and other components, reducing the amount of duplicate software components running on a Linux system.
Motivation: "Many of you know Lennart’s famous blogpost on how we put together Linux distributions. (...) The proposed solution, however, is not something which I am very excited about, at least not for the use-case of installing a simple application (...) the solution outlined by Lennart basically bypasses the distribution itself, instead of working together with it. This results in a duplication of installed libraries, making it harder to overview which versions of which software component are actually running on the system. (...) I wanted to explore a different approach of managing 3rd-party applications on Linux systems, which allows sharing as much code as possible between applications.
So unlike AppImage, Limba tailors software installations to the base operating system. In contrast to Limba, AppImage totally "bypasses the distribution itself, instead of working together with it".
Unlike AppImageKit, Limba allows applications to have dependencies to other packages. That creates the need for package management. So with Limba, you end up with 2 package managers: one in the base operating system and one provided by Limba. In contrast, AppImages are designed to have no dependencies that are not part of the base operating system. So you do not need a package manager to download and run them.
Limba uses OverlayFS to combine an application with its dependencies before running it, as well as mount namespaces and shared subtrees.
As cool as this is, it is not available and will not be for a while in older distribution releases such as CentOS 6.
Since the software components are located in separate directories under /opt/software, an application will not automatically find its dependencies, or be able to locate its own files. Therefore, each application has to be run by a special tool, which merges the directory trees of the main application and it’s dependencies together using OverlayFS.
Unlike AppImages, application packaged for Limba cannot just be downloaded and run by the end user. Rather, the user has to install a runtime (the "special tool") first.
http://listaller.tenstral.net/ (Matthias Klumpp)
According to this announcement from 2014 "This project has been superseded by Limba".
Listaller unifies the way you manage software on your Linux distribution, by providing an user-friendly application-centered software manager GUI.
So unlike AppImage, this is a package manager. Unlike AppImageKit, Listaller allows applications to have dependencies to other packages. That creates the need for package management. So with Listaller, you end up with 2 package managers: one in the base operating system and one provided by Listaller. In contrast, AppImages are designed to have no dependencies that are not part of the base operating system. So you do not need a package manager to download and run them.
We also provide a software setup package format (IPK-packages)
And unlike AppImages, regular packages are uses that must be installed.
which works on all Linux distributions and provide tools to make your application-binaries work on every distro.
ligcc by Hongli Lai (also found in Ubuntu in the limba-licompile package) is similar to AppImageKit's LibcWrapGenerator - more investigation is needed. Probably nothing prevents you from using ligcc for building your application and then packaging it as an AppImage.
Unlike LibcWrapGenerator, ligcc also can enforce static linking for some or all libraries. This sounds interesting and should be further investigated.
Listaller supports relocation. (...) However, most applications are not relocatable. The paths where in they search for data files are usually hardcoded at compile time.
Listaller uses BinReloc (a component that was originally developed for Autopackage), an API that uses dynamic linker and kernel magic to find out the full path of an application or library. This means that the upstream application author has to specifically change the source code. While this is a clean solution, it is also additional work and mandates patching and recompiling the source code, which might not be an option, e.g., for closed source applications. AppImageKit uses binary patching instead to replace hardcoded references to
/usr in the binary with the bundled equivalent inside AppImage. Nothing prevents you from using BinReloc in your application and then packaging it as an AppImage.
The package format is based on AppStream metadata.
AppImageKit is not yet using AppStream metadata but considering to do so.
You can publish your (signed) package anywhere on the web and have users install it using Listaller. Later, you might want to set-up and update-source for your software, so all users stay up-to-date.
Like AppImages, upstream application authors can host their apps for download without a central instance. But unlike AppImages, Listaller packages cannot simply be downloaded and run by end users; instead, end users have to install the Listaller runtime first.
There are 2 sample applications available for download. The applications are not packaged by the upstream application authors.
Now claimed by Canonical to be cross-distro, but appears to be mainly a frontend to a central App Store with Canonical as the gatekeeper and ubuntu-core as a required runtime (note that, with the implementation of base snaps, the core will be just snapd and basic tools and there will be a base on top which can be based on any distro).
Snappy appears to be about ensuring Canonical control first and foremost. A Contributor License Agreement (CLA) needs to be signed to contribute. The Canonical store seems to have a pre-eminent, centralistic place in the Snappy ecosystem. While Canonical claims everyone can operate a store, each device is allowed to have one store only. Also, everything is supposed to run "confined" by the system.
In contrast, AppImage is designed as a de-central system which gives all the power to application authors and end users, with no central intermediaries in between.
(Mike Hearn, Jan Niklas Hasse)
According to this announcement from 2010 "Listaller and the Autopackage project will merge. Autopackage will be integrated into Listaller and we work with distributors on improving the IPK package format."
Zero Install is a decentralised cross-distribution software installation system.
Applications must be installed when using 0install. Also you need to install 0install on the target system before you can run applications distributed with 0install (i.e., installing a runtime is required). In contrast, you can just download and run AppImages.
0install does not define a new packaging format; unmodified tarballs or zip archives can be used. Instead, it defines an XML metadata format (...) A single metadata file can be used on multiple platforms (e.g. Ubuntu, Debian, Fedora, openSUSE, Mac OS X and Windows), assuming binary or source archives are available that work on those systems.
Like AppImageKit, it does not magically solve backward binary compatibility of shared libraries.
The XML file describing the program's requirements can also be included in a source-code repository, allowing full dependency handling for unreleased developer versions.
Unlike AppImageKit, 0install allows applications to have dependencies to other 0install packages. That creates the need for package management. So with 0install, you end up with 2 package managers: one in the base operating system and one provided by 0install. In contrast, AppImages are designed to have no dependencies that are not part of the base operating system. So you do not need a package manager to download and run them.
As well as being able to download and manage 0install packages, 0install also allows programs to depend on native packages from the user's distribution.
This means that unlike with AppImages, 0install packages are installed very specific to a given host system, and hence cannot be easily copied from one machine to another running a slightly different host system.
0install is written in OCaml
This choice of programming language makes it hard for contributors, since not many people are skilled in OCaml. AppImage is written in C with some surrounding code in bash and python, languages many more people understand.
Roadmap: Sandboxing - Provide better integration with sandboxing systems such as Rainbow, Plash or LXC.
Like AppImageKit, Sandboxing is not the default in 0install yet but is on the roadmap.
OS X, Windows
Unlinke AppImageKit, 0install also targets the OS X and Windows platforms.
There is a software catalog of roughly 70 applications packaged using 0install. The applications are not packaged by the upstream application authors.
Nix is a purely functional package manager.
Call me clueless, but I actually have no clue what that means.
This means that it treats packages like values in purely functional programming languages such as Haskell
The description reads like it is made by computer scientists for computer scientists. I still can't figure it out. But unlike AppImage, it is a package manager.
It provides atomic upgrades and rollbacks, side-by-side installation of multiple versions of a package, multi-user package management and easy setup of build environments.
That sounds good. Seems like it is a package manager that deals with source code. Similar to a compile environment like Yocto?
Lists 11,000 packages that are supposed to be easy to build. But hey, even this impressive repository doesn't list the Subsurface app. How likely is it that it will ever be added? Could upstream do that on their own? Doesn't seem so.
bash <(curl https://nixos.org/nix/install ) # 67.1 M nix-env -i atom # installing ‘atom-1.4.3’ # these paths will be fetched (168.07 MiB download, 882.90 MiB unpacked): (...) ls /nix/store/ | wc -l # 1322
So in order to install the Atom app I can either download one 76 MB AppImage file, or 1.322 individual packages totaling 883 MB plus a 67 MB runtime. This feels like a distribution on top of a distribution. So probably Nix is a great system to build a distribution, but doesn't seem like a suitable tool to run a 3rd-party app on top of a distribution with minimal fuss.
Turns out it can be a great way to generate AppImages that bundle everything, starting with ld-linux.so and abovem, thus making AppImages that truly run on every Linux machine.
It's a package manager. Not one app = one file.
RadioTux Magazin November 2016
German podcast RadioTux Magazin November 2016 summarizes the differences around 22:00:
AppImage: Relativ einfach - anklicken, geht.
Snap: Man muss sich erst was installieren, man muss sich irgendwie bei Ubuntu One anmelden, aber dann kann man etwas installieren, geht.
Flatpak: Ich muss erst mal Flatpak besorgen, dann muss ich mir die Repositories da hinzufügen, dann muss ich mir die GPG Keys holen, dann muss ich mir Runtimes runterladen, und dann kann ich irgendwie die Flats da rausholen, installieren und die Programme starten.
Sozusagen aufsteigend nach der Schwierigkeit.
AppImage: Relatively simple - click, runs.
Snap: You have to install something, you have to login somehow to Ubuntu One, but then you can install something, runs.
Flatpak: I need to get Flatpak first, then I have to add the repositories there, then I have to get the GPG keys, then I have to download Runtimes, and then I can somehow get the Flats out of there, install and start the programs.
So to say, ordered according to difficulty.
NOTE: Logging into Ubuntu One is no longer required as of Q4/2017 (and has not been for a while); apparently this was a bug at the time of the review.
- Upgrading packaged Ubuntu application unreasonably involves upgrading entire OS
- On Snappy and Flatpak: business as usual in the Canonical propaganda department
- http://www.valdyas.org/fading/index.cgi/2016/06/17 and comments on https://www.reddit.com/r/linux/comments/4oihga/appimages_snaps_xdgappswflatpaks/
- Antithesis: http://kmkeen.com/maintainers-matter/
- c't Linux 2017: Praxis und Root-Know-How für den Linux-Alltag (German) https://books.google.de/books?id=mOmNDQAAQBAJ&pg=PA20&dq=appimage#v=onepage&q=appimage&f=false
- https://github.com/probonopd/AppImageKit/files/327061/evolution.pdf Caution: Might be humorous. Or not.