I don't like AppImage

Nowadays, a lot a Linux softwares are distributed as AppImage binaries. This way has a lot of advantages either for the user and the developer… But also introduce other issues than can annoy me when they’re occur.

This article will expose my point of view for this distribution method.

What is AppImage

Some history

AppImage is not recent, the project was born on 2004 under the name “Klik”. Klik was intended to integrate itself with the web browser and provide an interface that would fetch the prerequisites for a software and build it into a .cmg file. The user just had to download a “receipt” file and Klik executed it. It a very simplified way, it’s similar to Arch Linux’s AUR packages approach where the user can obtain predefined PKGBUILD files that Pacman executes to compile the software. The big difference is instead of creating binaries and libraries, it was a unique binary file that was produced.

PortableLinuxApps was the successor of Klik and kept most of its philosophy. Then, in 2013, the project was renamed again into AppImage that correspond to the binary format name produced by AppImageKit.

The principle

An appImage binary doesn’t install anything on the system. It doesn’t alter the host as you just need to download the file, make it executable, then launch it. The application is provided as a kind of container which possesses all dependencies required to work. At startup, the binary file is mounted as a filesystem by FUSE and the application is executed from here. By this way, the application does not require any administration grant to be installed or executed because everything is happening in user space.

AppImage advantages

One of the strongest thing in Linux ecosystem is also its biggest weakness : its diversity. There are a lot of Linux distributions that create as much complexity has they are numerous. Because of this, package building can be fastidious with of risks of dependencies hell, different versions depending of Linux distribution maintainer, delivery method than could vary, package manager constraints, and so on.

The first issue AppImage address is the diversity. By providing a universal binary, the OS layer is ignored and makes no difference, the binary can be executed on most Linux Distributions.

No more admin rights required, simplified installation : An AppImage binary is downloaded, made executable, then run. That’s all.

No need to install anything else, an AppImage binary is autonomous. It can also be copied on a LiveUSB system or used by different distributions with a dual boot.

Some other features : you can mount the image and inspect the filesystem, extract the content, etc.

Wait… AppImage almost have only advantages, so what’s your problem you grumpy old fart ?

– The other guy in my head

Why I don’t like them ?

They require more disk space

The first issue I have in mind is the image size. As they should contain all of their prerequisites to work, with their runtime, it takes some place. Because of this, the softwares provided like this need at least a decade of megabytes on disk. You’ll tell me that today, we have in standard 1TB disks on our computers, but I think that efficient resource usage should remain necessary.

I can’t resist to compare this issue with Electron based desktop apps. Electron is a framework that allow to execute web based softwares on Desktop environments. In fact, that’s just the Javascript engine of Chromium rendering the software… Resulting applications using at least 150MB of runtime to work… Multiplied by all applications based on it because each of them is providing its own environment.

But go back on AppImage, with Nextcloud client has an example because it’s provided as a RPM and an AppImage and see the package size difference.

102M Nextcloud-3.3.5-x86_64.AppImage
2,3M nextcloud-client-3.3.5-1.fc34.x86_64.rpm

Reason ? The AppImage binary contains all of the required library for the Nextcloud Client. The RPM contains only the binaries and some specific libraries. Of course this comparison is a little skewed because the RPM would pull the libraries dependencies. But, these libraries will be shared by other applications and could already be here.

## RPM content
16K	./lib
2,9M	./bin
8,0M	./share
11M	.

## AppImage content
6,1M	./bin
208M	./lib
10K	./libexec
2,7M	./plugins
9,0M	./qml
21M	./resources
8,2M	./share
18M	./translations
272M	.

Updates are fastidious

When you are a Linux user for a long time, you are used to the Packet Manager for application installation. This tool maintain the whole system packages and ensure they are at the last available version and manage the dependencies. You can also install the updates automatically if you ask for it.

So yes, one of the problems AppImage respond is the possibility to have package in a different version as the one provided by the distribution. For example, long time support distribution usually provide fixed libraries versions that only have security and bug update but no new features. Major versions would be provided in the next major distribution update, that could be in years.

However, what’s annoying my with AppImage is the updates are manual. There is an automated updater that exists, able to calculate the delta between two versions to optimize the bandwidth usage, but it require to be integrated by the package developer. That’s the same problem as developers who provide RPM packages outside a software repository, you need to download it manually to update.

If AppImageUpdate is a good solution to this issue, the problem is that’s a dedicated tool not integrated to the system. So you’ll need to trigger the update when the application notifies you about it. And again, it’s mandatory for the developer to implement it in its package.

I’ve tested with the various softwares I’ve installed with AppImage : Ultimaker Cura, Diagram.net, Infomaniak kDrive : none of them are compatible with AppImageUpdate.

Yup, none of them worked…

From my perspective, when you compare with a software manager that centralize and automate this maintenance, that’s a regression.

System integration

The autonomy philosophy of AppImage provoke a disconnection with the operating system. Like I said previously, if the developer didn’t implement the AppImageUpdate feature, the software update will be manual. If you want to have an AppImage running at system startup, you’ll also need to do it manually.

Example with kDrive sync client, based on ownCloud and exclusively provided as an AppImage. In the client options, you can ask it to automatically start at boot, and it works like any other native app. However, if you have installed it in the AppImage suggested way that is chmod a+x software.appimage, then run, we can see a problem.

The executable path is the AppImage file. If you omit to remove the previous one from the startup applications, it will be the old one that’ll start ! I’ve discovered this issue after an update of the AppImage and then, after a reboot, the “hey, update !” notification was here again.

The example also show another issue : the binary is in my “Downloads” folder (actually not, that was for the demonstration). So the operating system is becoming a big mess and you don’t know where the softwares are installed, because…

… An AppImage does not install itself into the Application Launcher. You’ll need to do it yourself in your Desktop Environment settings. At least, you may find it in the recent files list.

AppImage created a daemon to respond this problem, appimaged. This service is able to look into several directories to detect AppImage files, making them executable and even updating them if compatible. But when you already have a packet manager, why another layer ?

One last issue I can see with the idea of having your AppImage in your home folder is in case of Linux installation hardening (see the French National Information System Security Agency’s (ANSSI) recommendations). One of the recommendation is to apply the noexec flag on /home mount point. So AppImage could not work with this setting. Of course, almost none of Linux Desktop installation is set up like this, these recommendations are for server. But this limitation can happen.

On my side, I like to have an organized OS so I took the habit to store the AppImage files into a /opt/app_name folder.

Conclusion

AppImage responds very well to an old Linux issue and is a software distribution method that have a lot of advantages, as you may have seen during the introduction. However, its absolute disconnection from the OS force to manually maintain the applications and I think that’s a regression. The project created some tools to avoid it, but the developer still need to implement them.

What’s annoying me with AppImage it’s not their existence, it’s a great software distribution tool, but the laziness of those who are only using it to distribute their softwares. I think of Ultimaker Cura that is only provided as an AppImage when it’s just a Python based app. On my perspective, AppImage should be a parallel or fallback solution and not the standard. If so, it would need a better system integration.