AppImages are distro-agnostic and can run in all available distros. They need not be installed in the system. Users can carry these with them, and start working in a completely new system. The concept could be game changing for developers. Let’s see how it works.
As a novice Linux user, I choose a distro based on its architecture, stability, and the apps it can support. Among these three, I feel apps are an important factor because most Linux users are dependent on their distro’s app store or its repositories for their app needs. This is where Linux falls behind the Windows OS.
Generally, Windows users download apps directly from their respective websites, which provide the most recent version of these apps. Also, apps are downloaded as a single package and users can proceed with the installation right away. But in Linux, the approach is slightly different. The user goes to the distro app store or installs the app via the console by issuing a command. Each distro can have varying versions of the same app. So it is safe to say that there’s a lack of uniformity within the distros. To receive the most recent version of the software is not possible via the distro’s app store or its repositories, unless your distro is a rolling/semi-rolling release. Sometimes, users may face some issues like “dependencies are not matching” or “dependencies are missing”. In this case, users may struggle a lot because they have to find out the matching versions of dependencies, and install those versions in the system to finish the installation process.
But what if you can download a recent version of an app and, without installing it, start using it right away?
AppImage is a kind of app packaging system, which eliminates many obstacles in the traditional Linux app packaging. In this article, we will briefly look at this system and how it works.
What’s wrong with the traditional packaging?
Generally, the developer creates an app, and then releases it to the public. For Linux users, the developer needs to follow certain guidelines that are mandated by the various distros, so that the app can be incorporated into that distro’s app store. Since Linux is diverse and developers have to make their apps available to all users, they need to repackage the app for other distros.
Except for the rolling release OSs, many of the Linux OSs are derived from the stable distros. Users are restricted to use the app version that is provided by the original distro, mainly because the OS maintainers focus on the security and stability of the OS.
But, sometimes, users wish to use a recent version of the app. This could be difficult if they rely on the distro’s app store, because some distros can take months to provide updates for the apps. Also, when you install an app via the traditional package manager it will look for the dependencies required and the compatibility of the existing dependencies. And if any discrepancies are found, it will find the required packages and ask you to install those too. But this dependency resolution is specifically made for the particular system that you are working on. So, typically, when you want to install the same app in another system, you will need to repeat the whole process.
This situation gets more complicated if the distro is unable to find the dependencies for that app. In that case, you will have to find the compatible version of the dependencies (sometimes in a tarball, in which case, you will need to build these too) and install them separately into the system.
What is an AppImage?
An AppImage is an app bundle that contains the app in a binary form along with its dependencies in a single file. This is much like the .exe file for the Windows apps. All you need to do is to download the AppImage file, make it executable, and start running it.
Since AppImages are distro-agnostic, they can run in all available distros. They need not be installed in the system. Users can carry these with them and start working in a completely new system.
AppImages are bundled with all the pieces that are required to run that app. As they do not depend on the system libraries or files, they can run in an isolated environment without disturbing the host system. Any user can run these apps without the native permission restriction of the Linux system.
Also, AppImages are independent universal packaging systems; so users get to use the recent version of the app without having to wait for it to be included in the respective distro packaging.
Working with AppImages
To start working with AppImages, all you need to do is download an AppImage file and make it executable. This can be done via GUI or console. In the GUI way, you need to right-click on the AppImage and go to the ‘Permissions’ tab of the file, check the option ‘Allow this file to run as a program’, close the dialogue box, and double click on the AppImage to run it. The console way is fairly simple. Just issue the following command in your console:
$ chmod a+x AppImage_Name.AppImage
After the execution of the above command, the AppImage becomes executable, and to run it, issue the following command:
When you double-click on them, some AppImages will ask you to install a desktop file. If you click on ‘Yes’, the respective AppImage will be added to your Application menu like an installed app.
Once you’ve decided to uninstall an AppImage, you can just delete the AppImage file from the system. However, if you’ve chosen desktop integration for that file, you may leave some residual files in the system, and the deletion of these files is entirely optional.
Each AppImage is executed by mounting the AppImage file with FUSE (File System in User Space), which enables the user to create a file system at the user level, without touching the host file system at the kernel level.
Sometimes a user may want to take a look under the hood of an AppImage. For that, the AppImage needs to be extracted. To extract its contents, we need to provide the path to the AppImage file and choose the ‘extract’ option from the AppImage help menu.
For example, we can take the Museeks AppImage, which is placed in a folder called ‘Test_Table’.
To display the help menu of Museeks, the following command should be issued:
$ /home/tuxmachine/Test_Table/ museeks-x86_64.AppImage.AppImage --appimage-help
To extract the AppImage, the user needs to issue the following command in the console:
$ /home/tuxmachine/Test_Table/museeks-x86_64.AppImage --appimage-extract
This will extract the contents of the AppImage and place them in a folder called squashfs-root.
However, the extracting option is not available for all the AppImages. So if it is not possible via console, you can use the appimagetool to extract the contents.
AppImage has another awesome feature called ‘portable mode’. This enables the user to carry the app data along with the app itself. This feature is available in the recent versions of AppImage (built in 2017 or later).
Generally, the portable mode is enabled by creating a directory along with the extension (.home or .config) in the AppImage location. For example, if you want to enable the portable mode in the textosaurus app, then as a first step you need to change your current directory to the AppImage location and make that AppImage an executable one:
$cd Test_Table $chmod a+x textosaurus-0.9.7-f0908a3-linux64.AppImage
The next step is to create a directory to save the app configuration files:
After that, execute the AppImage and make some changes in the defaults (for example, changing the font and its size). Now, close the app.
To ensure that the configuration files are created properly, enter the following command in the console:
The above command will display the location of the configuration files. For our example, the output will be like this:
textosaurus-0.9.7-f0908a3-linux64.AppImage.home textosaurus-0.9.7-f0908a3-linux64.AppImage.home/.config textosaurus-0.9.7-f0908a3-linux64.AppImage.home/.config/Textosaurus textosaurus-0.9.7-f0908a3-linux64.AppImage.home/.config/Textosaurus/config.ini
AppImages use the Zsync2 algorithm for updation. This algorithm downloads the pieces that are changed between your local AppImage and the new AppImage, and could be very useful for the large size AppImages.
To update an AppImage you can either use AppImageUpdate or appimageupdatetool. The difference between the two is that the former is the GUI version and the latter is the console version. Download any one of these according to your needs, make them executable, and run them with the complete path of your AppImage that needs to be updated as an argument.
As an example, if you want to check whether a new version of AppImageUpdate is available, you can issue the following command in the console:
./AppImageUpdate-x86_64.AppImage / home/tux_machine/Downloads/AppImageUpdate-x86_64.AppImage
It will open up a progress bar to let you know the overall updation process.
AppImage is fairly young and is evolving, so this article would be incomplete if its pros and cons aren’t listed here.
Pros of AppImage
- Even though an AppImage contains the app along with its supporting files and libraries in a single package, its overall size is kept at a reasonable level by employing SquashFS, which is used to compress files, inodes and directories.
- AppImages is a decentralised system, so it is not controlled by a single entity. Anyone can craft an AppImage for his or her app, and host it in their site or list it in the crowdsourced directory like AppImageHub. Currently, it consists of a total of 689 apps.
- AppImages are capable of running in an isolated environment; so you can run multiple versions of the same app in a system. This is extremely useful when testing multiple versions of the same app.
- Since installation is not a requirement for AppImages, they can run in Live OS. This comes in handy when using Linux as a Live OS in a Windows installed system. You can use any AppImage in that environment.
- AppImages are built on the principle of One App = One File. So maintaining the AppImage is fairly easy, especially for the non-tech users.
- AppImages are entirely open source; so naturally, no proprietary apps are developed in the AppImage format.
Cons of AppImage
- AppImages remove maintainers from the equation. Hence, it is up to the developers to ensure that the ingredients of the AppImage should not be outdated and be properly vetted. This is additional baggage for developers.
- The size of an AppImage is higher than what the traditional .deb package may offer. For example, the installation of the Flameshot app via the APT method will require packages that are 217KB in size to be downloaded, but the size of the same app in AppImage will be 19.67MB.
- Apps in the AppImage format are fairly fewer compared to the traditional package managers; however, the number of apps in the AppImage format is gradually increasing.
AppImage is a good replacement for traditional package managers, but it is still a work in progress. Due to its many advantages, it has a lot of potential in the future for developers as well as the Linux community.