In recent years, three different distribution independent package formats have become more prevalent in the Linux systems. These new package formats are Snap, Flatpak, and App image. And there are few others who chose an entirely different route. Linux distributions like Endless OS and Fedora entirely depend on independent package formats to run applications.
Package managers enable developers to package, distribute, install, and maintain applications in Linux systems. Distribution independent package managers are different from the traditional package managers like ‘.deb’ and ‘.rpm.’ which are platform dependent.
Distribution independent package formats vs. Traditional package formats
Unlike traditional package formats, distribution independent package formats bundle applications with all the dependencies to install and run the app as a single package. Therefore, any software distributed by these package formats will run on any Linux system, which has supported the framework for that particular package format.
With traditional package managers, we have applications built for a specific platform, and users will need to install the required dependencies for the package to run on the system. That might seem to be a significant drawback in traditional package managers, but there is also an issue to note for the distribution dependent package managers.
When a developer makes use of distribution independent package managers to distribute his work, he has the full responsibility of ensuring the dependencies are up to date with the latest security measures. If ignored, the package will pose a security threat to the system. On the contrary, traditional software packages are maintained by the Linux distribution developers, ensuring that dependencies are updated with the latest security updates.
Snap vs. Flakpak vs. AppImage
In this article, we shall explore three distribution independent package formats – Snap, Flatpak, and AppImage, know their differences and summarize a few key findings.
1. Snap
Snap is a distribution independent package format developed by Canonical and first released in 2014. It was initially developed for Ubuntu but has been adopted by other Linux distributions like Arch, Linux Mint, CentOS, Gentoo, and Fedora, and also included support for the Snap framework.
The main aim behind this package format development was to come up with a single unified format for software packages to run in a wide range of devices. That includes IoT (IoT), embedded devices running Ubuntu Core (a minimalistic version of Ubuntu), and computer systems that ran some Ubuntu version.
Snap also offers an online app store – Snapcraft, where users can find and install the software packages. It creates a large pool where users can find all available a snap package. Snapcraft is itself controlled and maintained by the Canonical team.
Snapcraft
Other than app users, Snapcraft provides application developers with guidelines on publishing Snap packages. Additionally, Snapcraft comes with both open and proprietary software.
2. Flatpak
Like Snap, Flatpak is another distribution independent package format aimed to simplify overall app distribution and usage in Linux systems. Previously known as xdg-app, the framework was based on the concept of running applications in a secure virtual sandbox without requiring root privileges or posing a security threat to the system.
Flatpak was officially released in 2015 with a reliable backup from Red Hat, Endless Computers, and Collabora. It targeted primarily three Desktop Environments. That is FreeDesktop, KDE, and GNOME. The Linux distributions currently having this framework are arch Linux, Debian, Fedora, Mageia, Solus, and Ubuntu.
The Flatpak framework itself is developed in C programming and released under the LGPL license. The lead developer is Alexander Larsson – a Red Hat employee.
Like Snapcraft for Snap, Flatpak also has the Flathub app store where users can find and install all Flatpak packages. Initially, Flathub only allowed open-source publishing applications on the website but has recently approved the publishing of proprietary apps.
Additionally, unlike Snap, where we have a single repository controlled by Canonical to install and update software packages, Flatpak supports the use of multiple repos. The one significant disadvantage with this package is the lack of support for Servers.
3. AppImage
AppImage is another widespread distribution independent package format first released in 2004 with the name Kik. Regarded as a portable package format, this follows the “One app = one file” concept. That means, it is a regular independent file containing a single app and everything it needs to work. To run the application, the user only needs to make it executable and double-click on it to start.
Users can find the packages on the AppImage website. Another feature to note is that it does not use repositories to install package updates like Snap and Flatpak. Instead, the AppImage package comes with additional information on how to install updates. Packages without this update information can be updated with a tool like AppImageUpdate.
The table below gives a detailed summary of the key differences between Snap, Flatpak, and AppImage. Although most of the features are self-explanatory, we have elaborated some of them below the comparison table.
| Features | Snap | Flatpak | AppImage |
|---|---|---|---|
| Permission Controls Toggles (GUI and CLI) like in Android devices | Yes | Yes | No |
| Sandboxing Support | Yes | Yes | Yes |
| Sandboxing Mandatory | Yes | Yes | No |
| App Portability | Yes | Yes | No |
| Native Theme Support | Yes (with caveats) | Yes (with caveats) | Yes (with caveats) |
| Support for Bundled Libraries | Yes | Yes | Yes |
| Fully Contained Single Executable Support . Like an exe file for Windows systems | No | No | Yes |
| Online App Store | Yes | Yes | Yes |
| Multi-version Parallel Apps Support | Yes | Yes | Yes |
| Automatic Updates | Yes | Yes | Yes(with caveats) |
| Support for Chrome OS (through Crostini containers) | Yes | Yes | Yes |
| App Size | Can vary but higher than AppImage | Can vary but higher than AppImage | Lowest |
| Number of Applications Available in the App Store | Highest | Lowest | Somewhere in between |
| Plugins for Desktop App Store Software | Yes | Yes | No |
Permission Controls
Most applications need to access different system features to run smoothly. Luckily some of these package formats provide users with a simple way to control some of these permissions.
Snap provides both a graphical and a command-line interface for user-controlled permissions. You can use the Ubuntu Software to manage permissions of applications with Snap.
Leafpad permissions
From the above image, you can see the different permission for Leafpad. You can either enable or disable each permission by clicking on the toggle button.
To access permissions of a snap application via command-line run the command-line below:
snap connections leafpad
Replace ‘leafpad’ with your snap name.
Snap CLI permissions
To see all the installed snap applications, run the command below:
snap list
Snap List
To grant network permission to Leafpad snap, execute the command below:
snap connect leafpad:network
To revoke network permission, execute the command below:
snap disconnect leafpad:network
Snap CLI permissions
Flatpak also provides users with a permission control interface. You can use GNOME Software to manage Flatpak apps permissions graphically.
To see all permissions in a Flatpak app, run the command below:
flatpak info --show-permissions com.spotify.Client
Be sure to replace ‘com.spotify.Client’ with the name of your Flatpak app.
To view all Flatpak applications installed in your system, run the command below:
flatpak list
AppImage doesn’t provide user permission controls as of now. However, developers have hinted that this feature may be implemented in the future.
Sandboxing
Sandboxing is the process where an application runs in an environment (a sandbox/container/filesystem/archive) fully isolated from the host system. Any interaction with the system is done through APIs and user permissions. Snap, Flatpak, and AppImage offer support for Sandboxed environments.
A Sandboxed application enhances overall system security compared to an app with full system access. A good example would be android applications. They run in a sandboxed environment and have access to the system only via user permissions.
Native Theme Support
Both Snap, Flatpak, and AppImage package formats support the native look and feel for GTK and QT applications, though with some limitations. For example, Snap and Flatpak require the system themes packaged in their specific formats. If you are running third party themes and icon packs, you might not get the correct system theme, cursor, and app icons. Even though this has improved over time, there is still some notable difference from apps installed from the official package manager of distribution.
App Portability
An AppImage application is similar to the Windows system single executable’ .exe.’ file. An AppImage contains one app with everything it needs to work. To run the application, the user only needs to make it executable and double-click on it to start.
That is not the case with Snap and Flatpak applications. However, they can be made portable by packaging the app itself, and the child repositories it depends on. This whole process is not as easy as AppImage and requires running multiple Terminal commands.
Conclusion
Each of the three distribution independent package formats discussed above has its advantage and disadvantages. I think there are still some improvements by each of them to make any of them the main package format for Linux distributions. Luckily, all these package formats can co-exist. You don’t have to stick to a particular package format when you can enjoy software from different package formats.
8 comments
As far as I know, Snap is not allowed in Linux Mint 20. Like you said: “Snap, where we have a single repository controlled by Canonical to install and update software packages”
Canonical apparently wants to be the be the Apple store for Linux.
Mint 20 doesn’t come with snap but there’s nothing to prevent you from installing it. I understand their decision and agree it should be something that the user has to explicitly opt-in. But, Canonical wanting to be Apple is a stretch.
I installed the latest Manjaro GNOME recently and had weird dependency problems with spell check in every app that uses spell check (LibreOffice, Evolution and Zim), and I looked through the wikis, couldn’t find anything that fixed it (aspell and hunspell were installed). Then I see flatpak has the LO.7 (I have it on another machine, I like it, it’s new and shiny) so I uninstalled official repository and installed the flatpak. Works. So I did the same with Evolution and Zim. Works! That’s what I want, for apps to work.
I’m sure somewhere in the Arch wiki there is a solution but, really, it shouldn’t be difficult for a basic function like spell check to work. Although I’ve always tried to stay away from both snap and flatpak, this has changed my view on flatpak, at least from a functionality standpoint. I can’t say how more or less secure it is.
Windows .exe files don’t work like appimage, they also have dependencies, supplied by DDLs
There’s a mistake on the table you put “no” for the portability of appImage and “yes” for flatpak and snap
You obviously have never developed an application for Windows when you claim that:
> An AppImage application is similar to the Windows system single executable’ .exe.’ file.
It is in NO WAY self contained. It is the gateway to dependency hell.
You COULD make a self contained .exe application, but that is nothing like any of the app distribution technologies described here.
TYPO: Snap vs. FlaKpak vs. AppImage -> Snap vs. Flatpak vs. AppImage
None of these technologies is near to a perfect build-once-run-anywhere capability yet. And upgradeability and maintainability are very important. If FlatPak can expand to support servers then it would be the clear winner. Just have to see where they go with it.
linux wont win … its apps suck compared to commercial apps it never installs drivers for WiFi external cards grandma wont get on the net…lol