Reaching out to the AppImageKit devs: I absolutely love the AppImage format, but over my last 6 months or so of using them, I’ve found some fundamental issues that may be holding them back overall as an application distribution format, as well as some possible additions that could fix them without taking any abilities away.
Issues with current spec:
- There is no standard way to request minimum permissions to run properly such as Flatpak does.
- Integration with Firejail simply doesn’t work correctly most of the time. Most AppImages I’ve tested don’t even launch using it, and if they do, they lack the minimum permissions to function correctly without manually tweaking which can be intimidating to new GNU+Linux users, and AppImages are commonly targeted at them.
- Although this is mostly an app developer issue, a lot of AppImages do not work on all common GNU+Linux distros. Application devs are ultimately the ones who should ensure this, but it doesn’t happen enough regardless and many AppImages just straight up don’t work on some distros.
- There is no standard way to internally name applications such as the way native package managers and Flatpak do for centralized distribution (outside of the filename). For terminal programs, there is no standard way to request a launch command (such as being able to run ‘vim’ in the terminal to launch a vim AppImage), which ultimately requires users to write launch scripts.
- Request app devs to add a manifest file inside the AppImage, which gives all the minimum permissions in order to run properly, an internal program name (possibly following Flatpak’s style of reverse DNS?) for package managers to use, and a request to add terminal command(s) so users can launch the application from the terminal with no manual setup.
- This would be solved by solution #1. An optional launcher would be able to read the requested permissions from the AppImage, show the user what permissions are required, then launch the AppImage if the user agrees.
- If possible, a launcher would be able to run AppImages inside a Flatpak jail. This would give AppImages a standard system to run in, and would always be guaranteed to work when ran inside, exactly how Flatpaks can reliably run across different GNU+Linux systems with different libraries.
- This would also be solved by solution #1.
All additions would only be seen by a system launcher written around them, and the AppImages would still work exactly the same as they currently do without the launcher.
I believe these additions could allow for much better integration and security with less work for the user, but I’d love to hear your input on it. Frankly, I’m not a very good programmer, but I’d be willing to try my damndest at writing a proof-of-concept