Sure, you can enable it. That doesn’t solve the problem. The problem is that you cannot execute the app directly and need to use a wrapper script. steam-run and the like are hacks to get things working.
Do you know how binfmt_misc works? It makes it so that when you execute the appimage it automatically runs it with appimage-run, both flatpak and snap work in a similar matter, flatpaks need to be launched by flatpak run and snaps by snapd, however with binfmt_misc it removes the need to manually have to use appimage-run and it instead does it automatically for you.
So this makes no sense.
it’s still entirely author-dependent whether the app will work across different distros. The list of projects that use those tools is also quite small right now. Meanwhile, pretty much every flatpak I’ve tried has not been an issue.
Welcome to the world of centralized packaging systems that have requirements before running. flatpak or snap do not have this issue because they need runtime dependencies and setup before you can even try to launch any, you also likely get your flatpaks from flathub and I assume they at least test them once before publishing them.
probono once tried to enforce people to build their appimages on old systems to guarantee some quality and this was met with blackslash. 😹
steam-run and the like are hacks to get things working. They shouldn’t ideally be needed, especially with a format that is meant to work without issues across distros.
FYI, AppImage itself is older than NixOS and MUSL, the whole tooling is also controlled by boomers that want standards to follow and what not.
Basically AppImage was based off the idea of executable directories of MacOS, on those systems there is a some basic set of dependencies that will always be there.
AppImage instead tried to target the most common linux systems, which back then 99.99% of the time was going to be an FHS filesystem with glibc. glibc guarantees backwards compatibility*** so they made the rational decision (back then) of relying on some host dependencies and what not.
fastforward to 2025 and now linux is no longer that, you cannot even expect a system to be GNU/linux at all, nobody follows the FHS fully anymore. So the only thing you can complain about here is that appimage hasn’t moved fast enough to these changes but this is just a 100% community project, I think only KDE has contributed to appimage meaningfully in the past, there is nothing the likes of Red Hat or Canonical behind the project unlike flatpak and snap.
***Even this crap has had a ton of exceptions years later btw.
The official AppImage runtime has been static (no longer depends on any libfuse) and built with fuse3 since 3 years ago. Only electron builder remains with this nonsense of using the old runtime.
Also DWARFS AppImages that also do not need FUSE at all to run.