Convert Figma logo to code with AI

AppImage logoAppImageKit

Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat

8,712
559
8,712
257
View on GitHub

Top Related Projects

probonopd's avatar

linuxdeployqt

2,229

Makes Linux applications self-contained by copying in the libraries and plugins that the application uses, and optionally generates an AppImage. Can be used for Qt and other applications

TheAssassin's avatar

AppImageLauncher

5,775

Helper application for Linux distributions serving as a kind of "entry point" for running and integrating AppImages

Quick Overview

AppImageKit is a set of tools to create and run AppImages, a format for distributing portable software on Linux without needing root permissions. It allows developers to package applications with all dependencies, making them run on various Linux distributions without installation.

Pros

  • Portable: AppImages can run on most Linux distributions without installation
  • Self-contained: Applications include all necessary dependencies
  • No root permissions required: Users can run AppImages without admin rights
  • Easy distribution: Single file format simplifies software distribution

Cons

  • Larger file size: AppImages include all dependencies, increasing overall size
  • Limited system integration: May not integrate as deeply with the system as native packages
  • Potential duplication: Multiple AppImages might include the same libraries
  • Update management: No built-in update mechanism for installed AppImages

Getting Started

To create an AppImage:

  1. Install AppImageKit:
sudo apt-get install appimage-tool
  1. Prepare your application directory structure:
MyApp.AppDir/
  AppRun
  myapp.desktop
  myapp.png
  usr/
    bin/
      myapp
    lib/
      # Application libraries
  1. Create the AppImage:
appimagetool MyApp.AppDir MyApp-x86_64.AppImage

To run an AppImage:

chmod +x MyApp-x86_64.AppImage
./MyApp-x86_64.AppImage

Competitor Comparisons

probonopd logo

linuxdeployqt

2,229

Makes Linux applications self-contained by copying in the libraries and plugins that the application uses, and optionally generates an AppImage. Can be used for Qt and other applications

Pros of linuxdeployqt

  • Specifically designed for Qt applications, providing better integration and optimization
  • Simpler to use for Qt developers, with fewer configuration steps required
  • Supports automatic detection of Qt plugins and dependencies

Cons of linuxdeployqt

  • Limited to Qt applications, less versatile than AppImageKit
  • May not handle non-Qt dependencies as effectively
  • Less active development and community support compared to AppImageKit

Code Comparison

AppImageKit:

appimagetool /path/to/AppDir /path/to/output.AppImage

linuxdeployqt:

linuxdeployqt /path/to/app -appimage

Key Differences

  • AppImageKit is a more general-purpose tool for creating AppImages, supporting a wide range of applications and frameworks
  • linuxdeployqt is tailored specifically for Qt applications, offering streamlined deployment for Qt developers
  • AppImageKit has a larger community and more frequent updates, while linuxdeployqt is more focused but with less active development
  • AppImageKit requires more manual configuration but offers greater flexibility, whereas linuxdeployqt provides a more automated process for Qt apps

Both tools aim to simplify the process of creating portable Linux applications, with AppImageKit offering broader compatibility and linuxdeployqt providing a more specialized solution for Qt developers.

TheAssassin logo

AppImageLauncher

5,775

Helper application for Linux distributions serving as a kind of "entry point" for running and integrating AppImages

Pros of AppImageLauncher

  • Provides a user-friendly interface for managing AppImages
  • Integrates AppImages seamlessly into the desktop environment
  • Offers automatic updates for AppImages

Cons of AppImageLauncher

  • Adds an extra layer of complexity to AppImage execution
  • May not be necessary for users comfortable with command-line operations
  • Limited to desktop environments that support its integration features

Code Comparison

AppImageKit (core functionality):

int main(int argc, char *argv[]) {
    appimage_extract_and_run(argv[1]);
    return 0;
}

AppImageLauncher (integration example):

int main(int argc, char *argv[]) {
    AppImage appImage(argv[1]);
    if (appImage.shouldIntegrate()) {
        appImage.integrate();
    }
    appImage.launch();
    return 0;
}

Summary

AppImageKit is the core technology for creating and running AppImages, focusing on portability and simplicity. AppImageLauncher builds upon AppImageKit, providing a more user-friendly experience by integrating AppImages into the desktop environment. While AppImageLauncher offers convenience for less technical users, it may be unnecessary for those who prefer direct AppImage execution. The choice between the two depends on the user's needs and preferences for AppImage management and execution.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

AppImageKit irc Donate

The AppImage format is a format for packaging applications in a way that allows them to run on a variety of different target systems (base operating systems, distributions) without further modification.

Using the AppImage format you can package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, Ubuntu, Fedora, Debian and derivatives.

Copyright (c) 2004-24 Simon Peter probono@puredarwin.org and contributors.

https://en.wikipedia.org/wiki/AppImage

AppImageKit is a concrete implementation of the AppImage format, especially the tiny runtime that becomes part of each AppImage.

Providing an AppImage for distributing application has, among others, these advantages:

  • Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
  • One app = one file = super simple for users: just download one AppImage file, make it executable, and run
  • No unpacking or installation necessary
  • No root needed
  • No system libraries changed
  • Works out of the box, no installation of runtimes needed
  • Optional desktop integration with appimaged
  • Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
  • Can optionally GPG2-sign your AppImages (inside the file)
  • Works on Live ISOs
  • Can use the same AppImages when dual-booting multiple distributions
  • Can be listed in the AppImageHub central directory of available AppImages
  • Can double as a self-extracting compressed archive with the --appimage-extract parameter

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

If you have questions, AppImage developers are on #AppImage on irc.libera.chat.

Motivation

Linus addresses some core issues of Linux on the desktop in his DebConf 14_ QA with Linus Torvalds talk. At 05:40 Linus highlights application packaging:

I'm talking about actual application writers that want to make a package of their application for Linux. And I've seen this firsthand with the other project I've been involved with, which is my divelog application.

Obviously Linus is talking about Subsurface.

We make binaries for Windows and OS X.

Both bundle not only the application itself, but also the required Qt libraries that the application needs to run. Also included are dependency libraries like libssh2.1.dyliband libzip.2.dylib.

We basically don't make binaries for Linux. Why? Because binaries for Linux desktop applications is a major f*ing pain in the ass. Right. You don't make binaries for Linux. You make binaries for Fedora 19, Fedora 20, maybe there's even like RHEL 5 from ten years ago, you make binaries for debian stable.

So why not use the same approach as on Windows and OS X, namely, treat the base operating system as a platform on top of which we run the application we care about. This means that we have to bundle the application with all their dependencies that are not part of the base operating system. Welcome application bundles.

Or actually you don't make binaries for debian stable because debian stable has libraries that are so old that anything that was built in the last century doesn't work. But you might make binaries for debian... whatever the codename is for unstable. And even that is a major pain because (...) debian has those rules that you are supposed to use shared libraries. Right.

This is why binaries going into an AppImage should be built against the oldest still-supported LTS or Enterprise distributions.

And if you don't use shared libraries, getting your package in, like, is just painful.

"Getting your package in" means that the distribution accepts the package as part of the base operating system. For an application, that might not be desired at all. As long as we can package the application in a way that it seamlessly runs on top of the base operating system.

But using shared libraries is not an option when the libraries are experimental and the libraries are used by two people and one of them is crazy, so every other day some ABI breaks.

One simple way to achieve this is to bundle private copies of the libraries in question with the application that uses them. Preferably in a way that does not interfere with anything else that is running on the base operating system. Note that this does not have to be true for all libraries; core libraries that are matured, have stable interfaces and can reasonably expected to be present in all distributions do not necessarily have to be bundled with the application.

So you actually want to just compile one binary and have it work. Preferably forever. And preferably across all Linux distributions.

That is actually possible, as long as you stay away from any distribution-specific packaging, and as long as you do not use a too recent build system. The same will probably be true for Windows and OS X - if you compile on OS X 10.11 then I would not expect the resulting build products to run on OS X 10.5.

And I actually think distributions have done a horribly, horribly bad job.

Distributions are all about building the base operating system. But I don't think distributions are a good way to get applications. Rather, I would prefer to get the latest versions of applications directly from the people who write them. And this is already a reality for software like Google Chrome, Eclipse, Arduino and other applications. Who uses the (mostly outdated and changed) versions that are part of the distributions? Probably most people don't.

One of the things that I do on the kernel - and I have to fight this every single release and I think it's sad - we have one rule in the kernel, one rule: we don't break userspace. (...) People break userspace, I get really, really angry. (...)

Excellent. Thank you for this policy! This is why I can still run the Mosaic browser from over a decade ago on modern Linux-based operating systems. (I tried and it works.)

And then all the distributions come in and they screw it all up. Because they break binary compatibility left and right.

Luckily, binaries built on older distributions tend to still work on newer distributions. At least that has been my experience over the last decade with building application bundles using AppImageKit, and before that, klik.

They update glibc and everything breaks. (...)

There is a way around this, although not many people actually care to use the workaround (yet).

So that's my rant. And that's what I really fundamentally think needs to change for Linux to work on the desktop because you can't have applications writers to do fifteen billion different versions.

AppImage to the rescue!

AppImage usage

Running an AppImage mounts the filesystem image and transparently runs the contained application. So the usage of an AppImage normally should equal the usage of the application contained in it. However, there is special functionality, as described here. If an AppImage you have received does not support these options, ask the author of the AppImage to recreate it using the latest appimagetool (or linuxdeployqt).

Command line arguments

If you invoke an AppImage built with a recent version of AppImageKit with one of these special command line arguments, then the AppImage will behave differently:

  • --appimage-help prints the help options
  • --appimage-offset prints the offset at which the embedded filesystem image starts, and then exits. This is useful in case you would like to loop-mount the filesystem image using the mount -o loop,offset=... command
  • --appimage-extract extracts the contents from the embedded filesystem image, then exits. This is useful if you are using an AppImage on a system on which FUSE is not available
  • --appimage-mount mounts the embedded filesystem image and prints the mount point, then waits until it is killed. This is useful if you would like to inspect the contents of an AppImage without executing the contained payload application
  • --appimage-version prints the version of AppImageKit, then exits. This is useful if you would like to file issues
  • --appimage-updateinformation prints the update information embedded into the AppImage, then exits. This is useful for debugging binary delta updates
  • --appimage-signature prints the digital signature embedded into the AppImage, then exits. This is useful for debugging binary delta updates. If you would like to validate the embedded signature, you should use the validate command line tool that is part of AppImageKit

Special directories

Normally the application contained inside an AppImage will store its configuration files wherever it normally stores them (most frequently somewhere inside $HOME). If you invoke an AppImage built with a recent version of AppImageKit and have one of these special directories in place, then the configuration files will be stored alongside the AppImage. This can be useful for portable use cases, e.g., carrying an AppImage on a USB stick, along with its data.

  • If there is a directory with the same name as the AppImage plus .home, then $HOME will automatically be set to it before executing the payload application
  • If there is a directory with the same name as the AppImage plus .config, then $XDG_CONFIG_HOME will automatically be set to it before executing the payload application

Example: Imagine you want to use the Leafpad text editor, but carry its settings around with the executable. You can do the following:

# Download Leafpad AppImage and make it executable
wget -c "https://bintray.com/probono/AppImages/download_file?file_path=Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage" -O Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage
chmod a+x Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage

# Create a directory with the same name as the AppImage plus the ".config" extension
# in the same directory as the AppImage
mkdir Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage.config

# Run Leafpad, change some setting (e.g., change the default font size) then close Leafpad
./Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage

# Now, check where the settings were written:
linux@linux:~> find Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage.config
(...)
Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage.config/leafpad/leafpadrc

Note that the file leafpadrc was written in the directory we have created before.

appimagetool

appimagetool is a low-level tool used to convert a valid AppDir into an AppImage. It us usually used by higher-level tools that can be used by application developers to provide AppImages of their applications to end users. appimagetool itself is not needed by end users, and is normally not used directly by developers. Please see https://github.com/AppImage/appimagetool.

AppImage runtime

The AppImage runtime is a small piece of code that becomes part of every AppImage. It mounts the AppImage and executes the application contained in it. Please see https://github.com/AppImage/type2-runtime.

AppImageSpec

The AppImageSpec defines the AppImage format. Please see https://github.com/AppImage/AppImageSpec.