Version 1.0
Copyright © 2005-10 Simon Peter
Table of Contents
Abstract
The AppImage format is a standardized format for packaging applications in a way that allows them to run on target systems without further modification. This document describes the AppImage format.
This document is not a formal specification, since the AppImage format is not frozen yet but in the process of being specified more formally. However, this document is intended to describe the philosophy behing the AppImage format and the concrete implementation.
The AppImageKit contains a concrete implementation of the AppImage format and provides tools for conveniently handling AppImages.
Contributors are encouraged to comment on this document and propose formal format descriptions.
Historically, UNIX and Linux systems have made it easy to procure source code, however they have made it comparably difficult to use ready-made software in binary form. Especially the Free Software and GNU movements stress the fact that everyone should be free to get the source code. This mode of operation has worked well as long as the user base of these operating systems was largely comprised of technically advanced users. With the widespread adoption of easy-to-use desktop operating systems such as Ubuntu, the user base became less technically-minded and more application-centric.
Package mangers were introduced to mitigate the complexities of dealing with source code by providing libraries of precompiled packages from repositories maintained by distributors or third parties. However, the introduction of package mangers did not drastically reduce compexities or provide robustness - they merely stacked a management layer on top of an already complex system, effectively preventing the user from manipulating installed software directly.
Other systems, most prominently Windows and the legacy Macintosh operating system, have made it relatively simple for independent software publishers (ISPs) to distribute software and for end-users to procure and install software from said ISPs, without any instances (such as distributors or AppStores) between the two parties.
With the introduction of Mac OS X, arguably the first UNIX-based operating system with widespread mass adoption to a non-technical user base, Apple blended traditional UNIX aspects (such as maintaining a traditional filesystem hierarchy, including /bin, /usr, /lib directories) with common "desktop" approaches (such as "installing" an application by dragging it to the hard disk). While Apple uses a package manager-like approach for managing the base operating system and its updates, it does not do so for the user applications.
Open Source operating systems, such as the most prominent Linux distributions, mostly use package mangers for everything. While this is perceived superior to Windows and the Mac by many Linux enthusiasts, it also creates a number of disadvantages:
Centralization Some organization decides what is "in" a distribution and what is not. By definition, software "in" a distribution is easier to install and manage that software that is not.
Duplication of effort In traditional systems, each application is compiled specifically for each target operating system. This means that one piece of software has to be compiled many, many times on many, many systems using much, much power and time
Need to be online Most package managers are created with connected computers in the mind, making it really cumbersome to "just fetch an app" on an online system, and copy it over to another system that is not connected to the Internet.
A critical distinction between the approach known from Windows and the Mac and the one known from UNIX and Linux is the "platform": While Windows and the Mac are seen as platforms to run software on, most Linux distributions see themselves as the system that includes the applications.
While this leads to a number of advantages that have been frequently reiterated, it also poses a significant number of challenges:
No recent apps on mature operating systems In most distributions, you get only the version that was recent at the time when the distribution was created. For example, if you use Ubuntu Gutsy then you are stuck forever with the software that was recent at the time when Ubuntu Gutsy was compiled. Even if Firefox might have progressed by several versions in the meantime, you cannot get more recent apps than what was available back when the distribution was put together. That is like if you'd get only software from 2001 when you use Windows XP.
In the traditional model, the user has to decide: Either use a mature base operating system but be locked out of recent apps (e.g., using Ubuntu LTE), or be forced to update the base operating system to the latest bleeding edge version in order to get the recent apps (e.g., using Debian Sid).
This situation is clearly not optimal, since the common desktop user would prefer to hardly touch the base operating system (maybe update it every other year or so) but always get the latest apps.
No way to use multiple versions in parallel Most package managers do not allow you to have more than one version of an app installed in parallel. Hence you have no way to simply try out the latest version of an app without running the risk that it might not be easy to switch back to the older version, especially if the older version is no longer available in your distribution (e.g, old versions get removed from Debian Sid as soon as a newer version appears). This is especially annoying if you would simply like to try out a few things before you decide whether to use the old or the new version.
Not easy to move an app from one machine to another If you've used an app on one machine and decide that you would like to use the same app either under a different base operating system (say, you want to use OpenOffice on Fedora after having used it on Ubuntu) or if you would simply take the app from one machine to another (say from the desktop computer to the netbook), you have to download and install the app again (if you did not keep around the installation files and if the two operating systems don't share the exact same package format - both of which is rather unlikely).
The AppImage format has been created with specific objectives in mind.
Be Simple AppImage is intended to be a very simple format that is easy to understand, create, and manage.
Maintain binary compatibility AppImage is a format for binary software distribution. Software packaged as AppImage is intended to be as binary-compatible as possible with as many systems as possible. The need for (re-)compilation of software should be greatly reduced.
Be distribution-agostic An AppImage should run on all base operating systems (distributions) that it was created for (and later versions). For example, you could target Ubuntu 9.10, openSUSE 11.2, and Fedora 13 (and later versoins) at the same time, without having to create and maintain separate packages for each target system.
Remove the need for installation AppImages contain the app in a format that allows it to run directly from the archive, without having to be installed first. This is comparable to a Live CD. Before Live CDs, operating systems had to be installed first before they could be used.
Keep apps compressed all the time Since the application remains packaged all the time, it is never uncompressed on the hard disk. The computer uncompresses the application on-the-fly while accessing it. Since decompression is faster than reading from hard disk on most systems, this has a speed advantage in addition to saving space. Also, the time needed for installation is entirely removed.
Allow to put apps anywhere AppImages are "relocateable", this allowing the user to store and exectute them from any location (including CD-ROMs, DVDs, removable disks, USB sticks).
Make applications read-only Since AppImages are read-only by design, the user can be reasonably sure that an app does not modify itself during operation.
Do not require recompilation AppImages must be possible to create from already-existing binaries, without the need for recompilation. This greatly speeds up the AppImage creation process, since no compiler is usually involved. It also allows third parties to package closed-source applications as AppImages.
Keep base operating system untouched Since AppImages are intended to run on plain systems that have not been specially prepared by an administrator, AppImages may not require any unusual preparation of the base operating system. Hence, they cannot rely on special kernel patches, kernel modules, or any applications that do not come with the targeted distributions by default.
Do not require root Since AppImages are intended to be run by end users, they should not reqiure an administrative account (root) to be installed or used. They may, however, be installed by an administrator (e.g., in multi-user scenarios) if so desired.
The key idea of the AppImage format is "one app = one file". Every AppImage contains an app and all the files the app needs to run. In other words, each AppImage has no dependencies other what is included in the targeted base operating system(s). While it would theoretically be possible to create rpm or deb packages in the same way, it is hardly ever done. In contrast, doing so is strongly encouraged when dealing with AppImages and is the default use case of the AppImage format.
In short: An AppImage is for an app what a Live CD is for an operating system.