Image: Jack Wallen
I get why AppImages exist. They were the precursors for Flatpak and Snaps and made it possible for developers to create portable, universal applications that could run on any Linux distribution.
That, my friends, is a great idea. It’s also one that both Flatpak and Snap packages have succeeded to do. On my primary machine (a System76 Thelio), I install applications via source, apt, Snap and Flatpak–I don’t discriminate. As long as an application will install and run as expected, I’ll install it, regardless of the package format.
With one exception: AppImages.
I do not like AppImages and I believe it’s time developers stopped using them, but I get why they do. AppImages aren’t actually installed on systems. Instead, they are sort of like the containers of desktop applications, without having to rely on an installed engine like Docker. You simply download an AppImage, give it executable permission, and run it. The application in question should open and you could use it. Simple, right?
It was and it is.
There are problems with AppImages; problems that don’t occur with Flatpak or Snap applications. Those problems make me want to never use another AppImage again.
Let me explain.
SEE: Implementing DevOps: A guide for IT pros (free PDF) (TechRepublic)
It all started with Nextcloud
If you’ve read my ramblings long enough, you know I hold the Nextcloud on-premise cloud solution in the highest regard. It’s, without question, the best cloud platform any individual or business can install in their home or data center. With recent updates to their desktop client, that position was made even stronger…with a caveat.
If you’re using the Nextcloud desktop client (version 3) on either macOS or Windows, you get a native installer. Along with that installed application, everything works exactly as expected. However, if you use Linux, your only option is an AppImage. Don’t get me wrong, the AppImage works. You can download it, give it executable permission, run it, and connect it to your Nextcloud instance. The new end-to-end encryption works flawlessly.
The problem, however, lies in the inability to get the Nextcloud AppImage to autostart on login and integrate with the desktop menu. On the GNOME desktop, this simply doesn’t work. If I want to start the Nextcloud desktop client, I have to open my file manager, locate the AppImage, and start it from there.
Even though I have (in the Settings window) Launch On System Startup checked, the AppImage doesn’t do what it should.
In my experience with these types of applications, this is the norm, but even earlier AppImages used to integrate into the desktop. Now? That integration only works with some desktops. Here’s the results I’ve found:
-
GNOME: Application runs with no desktop integration and will not auto-start at login
-
KDE: Application runs with desktop integration and does auto-start at login
-
Deepin: Application runs with no desktop integration and no auto-start at login
-
Pantheon (elementary OS): Application runs with no desktop integration (not even a means to access the app from the panel) and no autostart at login
Do you sense a theme here? Neither do I. It is that inconsistency that has me scratching my head at the AppImage claim of universality.
That’s because there is no universality with so many AppImages. Not even close.
Unless you’re running KDE, you’re out of luck getting the Nextcloud desktop client to work as expected. I even attempted to create a systemd startup file for the Nextcloud desktop client on GNOME, to no end. I pulled every trick I had out of my hat and could not get that AppImage to start at boot. Nothing.
However, with both Flatpak and Snap packages I can always count on a consistent experience. Unfortunately, the newest release of the Nextcloud desktop client isn’t currently available as anything but an AppImage. Unfortunately, the only desktop client that’s available in the repositories is an out of date release that doesn’t include the new end-to-end encryption.
Since I’ve been using Linux, I’ve installed and used applications from just about every conceivable package type. I get the idea driving AppImages: They make it far easier for developers. Instead of having to create a build for every possible combination of distribution and desktop, they only have to create a single packaged AppImage. Thing is, those AppImages are rarely consistent across the board. What happens when someone’s experience with an app on their desktop/distribution combo of choice is less than expected? They probably stop using said app and move on to another solution. Or worse, it gives a new user a bad impression of Linux as a whole.
The possible dark side of AppImages
Here’s another issue I have with AppImages. On the rare occasion I’m willing to use an AppImage, I will only do so when I absolutely trust the developer. Why? Remember, an AppImage is an application you simply download and run. Anyone can build an AppImage, proclaim it a must-have piece of software, roll something nefarious into it, and make it available for download. Users then download that AppImage, give it executable permission, and run it.
Next thing you know, Mark Antony is crying, “Havoc,” and demanding the dogs of war be released.
Given the rising popularity of Linux, my guess is we’ll be seeing more and more attacks aimed at the platform. Do you want to blindly trust AppImages? I’m not sure I do.
What’s the solution?
I have an idea for one particular solution; the solution lies in the hands of the developers. First off, the universal nature of AppImages needs to be revisited. Either an app is universal or it’s not. I don’t know if the fault lies in every desktop developer to ensure that AppImages work seamlessly, or if it’s in the hands of those who maintain AppImage.
Either way, something has to give with this packaging system. Because I know these issues aren’t isolated to the Nextcloud desktop client, the problems need to be given the attention they so deserve. I’ve experienced issues with AppImages since I’ve been using them. Those problems never fail to have me rolling my eyes every time I see a Linux application available only via AppImage. My inclination is to metaphorically turn around and walk away from the app. Why? Because I know the application will fail me on some level.
Quite frankly, I don’t have time to dive down each and every rabbit hold presented to me by an application that should “just work.”
I love that Linux has so many options and possibilities, but every so often I step back and think, “Maybe so many options isn’t always the best thing.” It’s time to reevaluate what’s best for the Linux desktop and which route might lead to the widest possible acceptance of the open source operating system. After all, isn’t that lofty goal of “world domination” still in play? With that in mind, maybe it’s time to rethink, revisit, retool, or rebuild the AppImage.
