I got the chance to try out setting up an AppImage app for my brother, and now I can say that it has an absolutely awful UX.

AppImages are just apps and their libraries bundled into one file. You download it, you run it. Simple enough, right? However, the caveat is that these files are likely not marked as executable when you download them.

Scenario: you are a new user to Linux. You go looking for an app, and see that it has a download. You get the AppImage, open your file manager, then click it. Your computer will tell you that there's no way to open the file. Where do you go from here?

AppImages rely on the prior knowledge of how the executable bit works and how to set it. Users without that knowledge will hit a roadblock, and that's not the only one.

From what I know, AppImages are supposed to offer to set up a desktop file for the application on first launch. This one didn't do that. So, a new user might not know they need to go back to the file each time they want to run the app.

In addition, there are updates to worry about. If an AppImage'd app doesn't check for updates and you don't know you need the AppImage Update app installed, you will never get an updated app. A file from a website, like in the case I came across today, might have no indication of what you need to stay up to date.
I also take issue with the architecture of AppImage in comparison to flatpak. By default, AppImage is unsandboxed. There's "optional sandboxing", but I doubt users will put effort into installing another program and setting up sandboxing manually. If the goal is to protect users, sandboxing needs to be a seamless default.
There's also the awful setup process. https://gitlab.com/inkscape/inkscape/commit/24b5b6861dc80ef80c18cc0b26bb448b74500b1b tells me a few things:

• You need to write two scripts to generate an AppImage

• AppImage builds are locked to the packager's distro

This makes me think that AppImage is not suitable for development like flatpak and potentially snap are.

@brainblasted I recall the instructions on the website saying to compile out on the most out of date distro you can get your hands on, so it'll capture versions of the libraries that'll work across most distros.

Which makes it very poorly suited to me.

@alcinnz @brainblasted AppImage does run everywhere, if you want a single file executable for a broad range of platforms it is definitely a working solution.

@alcinnz @brainblasted IMO you shouldn't install apps you can't trust, and that is part of why I think Flatpak, Snap and AppImage are not something I want to rely on.

Package maintainers should be QAing each package, ensuring it has no anti-features, and pushing updates through my package manager. Bypassing this process gets us into a situation where Devs can do nefarious things without oversight from nearly anyone.

@bikecurious @alcinnz I agree that you shouldn't install apps you don't trust, but that doesn't stop some people from trusting proprietary apps. So if it's inevitable that someone wants to use them, they might as well be protected.

I disagree on having package maintainers block things. Users should be provided the tools and information needed to make decisions, and beyond that app management should be between them and the developer.

GNOME Software does this by showing permissions and telling you when a sanboxed app requests more permissions.
@bikecurious @alcinnz AppImage does run everywhere, but in my opinion there are better solutions to the problem, like flatpak and snap.