Comparison Between Snaps, Flatpak, and AppImage Packages

1. Overview

In this tutorial, we’ll learn about the different containerized application packaging formats in Linux. Additionally, we’ll do an in-depth comparison between the formats.

2. Software Package Formats

In Linux, a software package is a collection of files that make up a software application. Its purpose is to simplify the installation and maintenance of software applications in the system. There are two main types of package formats in Linux: distro-native packaging formats (such as deb and rpm) and containerized application packaging formats (such as Snap, Flatpak, and AppImage).

The major distinction between the two types of package formats is the way they handle the dependencies of the application. The former group expects dependencies to be available on the system, though most of the frontend package managers (such as apt and yum) would read the dependencies list and ensure that it’s there in the system.

On the other hand, containerized application packaging formats — like Snap — pack the dependencies together with the application in the same package. This ensures that there will be no conflicts of dependencies between different applications. For example, if applications A and B require different versions of the same dependency, the packages would’ve packed applications A and B with the required dependency within the package. The downside of having the dependencies in the application package is that the application size is generally larger.

Within the containerized application packaging landscape, the most popular packaging formats are Snap, Flatpak, and AppImage.

2.1. Snaps

Snaps is a packaging format developed by Canonical, the company behind the Ubuntu Linux distribution. The Snap package packs the application along with all its dependencies, removing the need to manage the dependencies of the application separately. Besides that, the Snap packages are listed on a centralized repository, known as the Snap Store. This centralized repository makes it easy for end users to browse and install available applications.

Behind the scenes, there’s a daemon process, snapd, that performs various tasks to manage the Snap packages — for example, fetching package files from a remote repository when we install a Snap package. Besides that, it also runs these steps prior to running Snap packages, such as mounting, creating a sandbox, and running the application. To interact with the snapd daemon, we use the snap command-line tool. Additionally, we can use the snapcraft command-line tool to create the Snap packages and optionally publish them to the Snap Store.

2.2. Flatpak

Flatpak is another packaging format in Linux that aims to make it easy to distribute applications. In Flatpak, every application package is built against a runtime. This runtime provides the basic dependencies for the application. One example of the runtime is the Freedesktop runtime, which provides a set of essential libraries such as D-Bus, GLib, Gtk3, and X11.

When an application requires more dependencies than those available on the runtime, the developer can bundle the dependencies as part of the application. This allows the author to either use libraries that are not available on the runtime or use a different version from the one that the runtime provides.

To manage the Flatpak packages, we can use the flatpak command-line tool. Through this tool, we can list, install, update, and remove packages. Additionally, flatpak-builder is the command-line tool for building a Flatpak package.

2.3. AppImage

AppImage is a packaging format that packs the whole application, including its dependencies, into a single file. In fact, on the pages that host the AppImage packages, we can always see AppImage’s motto: “one app = one file”. In contrast to Flatpak and Snap, the AppImage package itself is the final executable program. This means there’s no installation of the AppImage package in the traditional sense. In other words, the AppImage package on Linux is akin to the portable .exe file on Windows.

3. Comparison Between the Package Formats

Despite sharing the same goal of making the application lifecycle easier to manage, there are various differences between the different packaging formats. In the following sections, we’ll look at these differences in detail.

3.1. Application Installation

For Snap and Flatpak, we run the install command on the snap and flatpak command-line tools, respectively, to install the package. For example, let’s see how we’d install the Discord application using snap and flapak:

$ sudo snap install discord
$ sudo flatpak install com.discordapp.Discord

Internally, the tools will look up the package on the remote repository and download the file locally. Additionally, the tools install the missing runtime (in Flatpak) or base snaps (in Snap) that the package needs. Then, for Flatpak, it’ll decompress the package before storing it on the disk, completing the installation process.

However, for AppImage, there’s technically no such installation process. This is because the package itself is an executable that we can run to start the program. One thing the end user will need to do after downloading the package is to set the executable permission bit of the package to make it executable.

3.2. Application Execution

To execute a Snap package application, we’ll need to invoke the snap run command with the package name. For example, to run the Discord application:

$ snap run discord

Behind the scenes, the snapd daemon will perform all the necessary steps prior to launching the application.

Similarly, to run the Flatpak packages, we’ll execute the flatpak run command. Particularly, the flatpak run command expects the package name in its fully-qualified domain name form:

$ flatpak run com.discordapp.Discord

On the other hand, to run an AppImage package, we can simply run the package itself on the terminal without any other command-line tools. For example, if we’ve saved our Discord AppImage package as discord.AppImage, we’ll run it on the terminal with ./discord.AppImage:

$ ./discord.AppImage

3.3. Application Size

Application packages are always distributed in their compressed form. This helps with the internet bandwidth of distributing the application. When the application is installed on the client side, depending on the package, the package might be stored and run as compressed or decompressed. For example, the Snap packages are always stored and run compressed. Similarly, the AppImage packages are never uncompressed on the client side. Storing and running packages compressed has the added benefit of reduced disk space usage.

On the other hand, the Flatpak packages are always decompressed on the client side. This means the Flatpak packages are almost always bigger than both Snap and AppImage packages.

To illustrate the file size differences among the different packaging formats, we can install the Discord application version 0.0.28 with each of the three package types. Using the Snap package, the size of the application on the disk is 89.1 MB, which is the smallest. Then, the AppImage of the same program with the same version is 98 MB in size. Finally, the Flatpak package of the Discord application is 237.1 MB in size, the largest among the three packages.

3.4. Sandboxing

Sandboxing refers to the practice of running the application in an environment isolated from the other applications on the system. This sandbox isolation prevents a malfunctioning application from disrupting the stability of the system. Additionally, sandboxing improves security as malicious code inside a sandboxed application cannot affect the system.

The Snap and Flatpak packages are always run in a sandbox environment. On the other hand, the AppImage package does not, by default, run in a sandboxed environment. To run AppImage in a sandboxed environment, we’ll need to explicitly run the AppImage package using sandbox software such as firejail.

3.5. Distribution

The main distribution channels for Snap, Flatpak, and AppImage are Snap Store, FlatHub, and AppImageHub, respectively. These main distribution channels contain the most packages published for the respective packaging formats.

In addition to the main distribution channel, the Flatpak command-line tool supports other self-hosted remote repositories. On the other hand, snapd does not allow changing the remote repository. Therefore, to utilize the Snap package manager functionality, the Snap packages must always come from the Snap Store.

3.6. Application Updates

Most of the time, applications rarely stay the same for too long. We’ll need to update the application once in a while so that we get newer features and security patches. To ensure the application packages are always up to date, the snapd daemon checks for Snap package updates four times per day. If there’s any update available, the snapd daemon applies the update automatically. Unlike the Snap package, Flatpak and AppImage do not have a daemon process that constantly updates the application automatically. Instead, users are expected to check on the available updates and apply them manually.

To update the packages, all three package formats support efficient binary delta update. This means the client only needs to download the difference between the binaries and apply it to the local package. This results in a more efficient update process as the client does not have to fetch the entire package content again. For AppImage, the support of binary delta update does not come by default and is handled by a separate program, AppImageUpdate.

4. Summary of Comparison

Let’s summarize our comparison of these three package formats and tools so far in a table:

$ sudo snap install discord 

$ sudo flatpak install com.discordapp.Discord 

$ snap run discord 

$ flatpak run com.discordapp.Discord 

$ ./discord.AppImage 

5. Conclusion

In this tutorial, we’ve learned about the three most popular containerized application package formats in Linux, namely Snaps, Flatpak, and AppImage. We’ve learned that all three package formats pack the application along with all its dependencies in the same package. This is in contrast to the traditional distro-native packages like deb or rpm, which install the dependencies as separate binaries in the system.

Then, we compared and contrasted the different formats from different aspects of an application package. The aspects we’ve compared include the application installation, execution, updates, size, and package distribution. The similarities between the formats highlight the fact that they are aligned in the goal of making application installation in Linux easier.