From Knowledge Center
AppImages are a new cross-distro package format. They don't require admin rights to run, they can be run from anywhere, they can be installed side-by-side with different versions, and they are incredibly easy to remove. In addition, They are supported by developer tools like AppImageAssistant that make it easy for developers to create AppImages.
What Makes AppImages Different
AppImages are cross-distro
From the beginning, AppImages have been designed to work on elementary, Fedora, OpenSuse, and Ubuntu without installing any sort of extra software. For developers, this means no more distributing applications in different package formats for different distros.
AppImages don't require installation
Normally, Linux programs are installed by running a script with administrative privileges; This script scatters files all over the filesystem. AppImages are self contained, they can be placed anywhere, and 'uninstalling' is as simple as deleting that single AppImage.
AppImages don't require administrative rights
Since AppImages run without installation, they don't require the elevated privileges associated with modifying the filesystem outside of your own home folder. This is much more secure than allowing an application access to the entire filesystem. On the off chance that you download a malicious application, the AppImage model limits the damage that application can do.
How AppImages Work
An AppImage is essentially an ISO with an executable bit at the beginning. When you run an AppImage, you are really mounting a virtual filesystem on top of your actual filesystem via fuse.
The AppRun script ties the two filesystems together so that the AppImage will use libraries and other resources from your system. Just like any other application, an AppImage will store its configuration data in your home folder. It'll even use your same configuration data from non-AppImage installations of that application.
AppImages should be distributed through some form of centralized repository system. This is for a few very important reasons:
- Discoverability: Users will not have to search the internet to find new software. They will simply return to the single place they know they can find all available software. This works in developers favor as well as they will pool their marketing efforts to encourage users to visit this single place.
- Security: Software hosted in a centralized repository can be screened prior to making it publicly available. In this way the repository can become a "trusted source" where users do not have to worry about malicious software. Again this works in developers favor because users will be less cautious in trying out new software.
- Quality Assurance: Software hosted in a centralized repository can also be screened for quality. Does the application do what it is advertised to do? Users will also be more likely to try new software if they know that applications hosted in the repository are typically high quality.
Of course, AppImages can also be distributed in many other ways if the developer so chooses.
Currently, AppImages do not provide a reliable method to keep software up to date. The specification must be amended to include such a method. Currently, it seems the best method is to provide an "updater" app. Here are some pros and cons of using such a method:
- Easier to add multiple sources to check for new apps.
- Ability to update all apps at once.
- Update experience is consistent across all apps.
- Works for both mixed systems and systems with only AppImages.
- Apps will either have to be stored in a single location or we will have to search for them (which will take time).
- Requires another application to be installed.
Currently, package maintainers are assumed to either:
a. Package all an applications dependencies inside its AppImage (excluding those already present in the intended base system)
b. Provide users with instructions to resolve dependency issues.
This is not an optimal solution. Steps should be taken to provide automatic dependency resolution.
one proposed solution includes making use of Smart Package Manager
Currently AppImages contain a standard *.desktop file. This contains the following relevant information:
- Icon: The Application's icon to be displayed on the desktop, in menus, etc.
- Categories: The category of applications this application belongs to. Ex: GNOME;GTK;Network;InstantMessaging
- Comment: A simple description of the application. Ex: Instant messaging program supporting text, voice, video, file transfers, etc.
- Name: The human readable name of the application. Not the binary name. Ex: Empathy Messaging Client
In order for an updater to function at least version information will have to be ammended. However, we may want to see what other relevant metadata we should include.