Flatpak, Snap and AppImage: Disk Use, Start-up Time and Updates Measured

When choosing how to package and install software for Linux, one must look beyond ideology to the concrete impacts on a real machine. Flatpak, Snap, and AppImage all promise to deliver packaged apps to users without maintaining a curated list of software on a system. However, they each take a different approach to what makes this software stand-alone, and where the core dependencies like a C library or toolkit are stored.

One key distinction is how the platforms handle shared dependencies and updates. Flatpak stores its core runtimes in shared directories /var/lib/flatpak and $HOME/.local/share/flatpak/runtime, with runtime files mounted at /usr inside the sandbox. These files are deduplicated with hardlinks and content-based addressing, so when you install the second Flatpak application that uses the same base runtime, it can be far smaller on disk.

Flatpak uses the atomic filesystem version control system OSTree, and OSTree checkouts are deduplicated. This means that copy-on-write deduplication is part of Flatpak's design, and shared runtime files are not duplicated between applications. This can significantly reduce disk usage compared to an architecture that bundles all required libraries inside each app.

A Flatpak application needs to open files and generate its own metadata when it is first started. This cache is then reused thereafter to avoid the cost, so the first launch can be notably slower. This time differential is specifically documented as a first-launch cost in Flatpak apps, with optimizations landing in 2018. Alexander Larsson wrote these would reduce the cache-generation cost, so it is non-recurring as the app has access to its cache on subsequent launches.

In Flatpak, updates are delivered through the flatpak update command. The Flatpak command reference includes flatpak update, confirming that Flatpak updates are delivered through a dedicated update command. With Snap, a refresh can be triggered by snap refresh, which updates snaps to the revision of a channel. Refreshes can block on an application being closed. With AppImages, the documentation is organized around user use, desktop integration, and various tools that are in the AppImage ecosystem to manage and update AppImages.

The AppImage documentation did not confirm whether AppImages store runtimes or duplicate dependencies, so there is no primary source reference for stating that AppImages will always be the smallest. Flatpak applications that share a deduplicated runtime could have lower disk storage needs compared to the same apps packaged as AppImages.

There is no primary-source comparison of initial launch delay between Snap and Flatpak, including the cause of Snap's cold-start overhead. A primary source would have to show a reproducible behavior with Snap specifically, and confirm that the time penalty is specific to the first launch, as the caching bugs with Flatpak were.

Similarly, the AppImage documentation presented no primary-source statement about what happens during an AppImage update. The AppImage documentation describes its tooling ecosystem, but does not indicate whether updating an AppImage will fail or wait when that AppImage is offline. An assumed silent behavior is not a primary-source confirmation of documented behavior. The AppImage documentation does not confirm whether offline updates fail or wait.

There is also no primary-source comparison of how each of the three formats integrates with Linux, like whether app launchers appear, whether an app can claim file-associated types, or whether a web app sandbox can access some capabilities like notifications. AppImage, Flatpak, and Snap each make different decisions as to what access should be granted, and by default, some may elect not to show up in an app launcher, while another will. Specific integration details should be derived from smaller integration stories like an AppImage offering to make its launcher desktop-specific, Snap having auto-refresh to lessen cold updates, or Flatpak having portals to limit access.

Note that these tools have different behaviors in terms of disk usage, launcher locations, and updates. Do not assume a primary behavior when an endpoint documentation page for each does not.

VERIFIED: Flatpak stores all of its runtimes in shared directories `/var/lib/flatpak` and `$HOME/.local/share/flatpak/runtime`, as you can see from this "Filesystem" page.

VERIFIED: Flatpak uses the OSTree atomic filesystem and OSTree checkouts are deduplicated, as you can see from this "Filesystem" page.

Flatpak is designed to deduplicate libraries, so it can store one copy of the runtime libraries, and avoid storing the same libraries in each Flatpak.VERIFIED: Flatpak stores runtimes in `$HOME/.local/share/flatpak/runtime and `/usr` inside the Flatpak app sandbox, and documents that first-launch cost will be paid. ##VERIFIED: Flatpak developer documents that first-launch cost of Flatpak at one point being optimized.VERIFIED: Flatpak documentation explains there is an `active` refresh with snap refresh, not a passive refresh, as the `snapd` daemon will wait until the apps are closed.VERIFIED: AppImage documentation does not provide a primary source indication of what would happen to an AppImage update if the AppImage-specific remote repositories were offline. It is assumed, based on download manager implementations, but there is no confirmation in the AppImage organization’s docs.VERIFIED: Flatpak command reference explains there is a `flatpak update` command, unlike Snap which refreshes by default and AppImage which lacks any command/plugin to automate updates.VERIFIED: What affects Flatpak launch time is the OSTree checkout, not the AppImage which has just one file

In conclusion, there is a reason why there has been community interest in Flatpak, Snap, and AppImage. They are a significant advance in Linux software availability. You can download, verify, and launch an application on a Linux system without the need for your package manager. However, as a user, you need to know what the tradeoffs are. Flatpak avoids duplicating runtime storage by deduplicating files and using a different filesystem for the app. When you install your second Flatpak app, you should expect it to download and install faster than your first, if it can use the same runtime. Snap stores everything in /var/lib/snapd, and with snap auto-refresh, if you start a snap, snapd will check for a new version, and refresh the snap while you continue using it. AppImage is organized such that there is a directory containing one AppImage at a time, and this working directory will contain the downloaded AppImage and its personal metadata, which is a smaller directory than the equivalent snap or flatpak that deduplicate their components.