I see a lot of people asking about state of AppImage support in Discover.
It’s non-existent, because AppImage does not require centralized software management interfaces like Discover and GNOME Software (or a command-line package manager). AppImage bundles are totally self-contained, and come straight from the developer with zero middlemen, and can be managed on the filesystem using your file manager
This should sound awfully familiar to former Mac users (like myself), because Mac App bundles are totally self-contained, come straight from the developer with zero middlemen, and are managed using the Finder file manager.
It’s the same model. For 20 years, there was no centralized Mac App Store because this distribution model doesn’t require it. Apple did eventually create one, but it’s a shadow of the iOS version, and a lot of popular Mac developers never got on board, continuing to distribute software themselves and update it in the way they choose (often with Sparkle).
When a format’s primary advantage is decentralization and independence, you don’t need a centralized piece of software like Discover do manage it. Of course, it would be nice to be able to have a centralized location to browse AppImage vendors, but a simple website could accomplish that.
AppImage isn’t currently a part of our design because Software Stores aren’t a part of AppImage’s design. We don’t oppose it–nothing of the sort! But the format isn’t relevant to what Discover does. If you want to use AppImage, go ahead! It’s a great format, and you don’t need our help to do it.
Adventures in Linux and KDE 
Not entirely true, though… It /is/ inherently a part of the design, since the KDE Store is planning on exposing AppImage (and indeed others) through KNewStuff. With some new functionality that’s being proposed for OCS (and implemented in the Store server as of about a week ago), this is now a thing that can be actually worked on. So, it’s very much a part of Discover, because Discover already supports KNewStuff 🙂
For some more details on said proposal, it’s tracked at https://phabricator.kde.org/T6133 and was discussed at the OCS BoF at Akademy, which i talked about here: http://kath-leinir.blogspot.co.uk/2017/08/services-collaborating-openly-at.html
However, the basic argument is very much true: AppImage doesn’t /need/ this, it’s simply a nice thing to have 🙂
LikeLike
That’s very interesting, thanks for the info! Working on cleaning up store.kde.org has been on my to-do list for a while; would you like to collaborate on that? Is the project’s Phabricator workboard a good place to centralize communication, or is there another medium?
LikeLike
Probably the best place for that, yes – it’s the main contact point for everything Store related 🙂 i’m also on the Discover telegram group (leinir there as everywhere else), so for chatting that works 🙂
LikeLike
What one would like with appimage is ability to add appimage repos and list them as install options and installing appimages by downloading them into some app folder and creating desktop shortcuts and or menu launchers. This isn’t much but it would improve on the usability of appimage.
LikeLiked by 1 person
Many users, including in my teams, do not comprehend the difference between Appimage and other packages found in Discover.
For most of us, we’d want a single central place (Discover) where we can see what’s installed, what isn’t installed that we might want to install, and what needs updating.
The technology/repositories behind it are not relevant to most users.
Thus, if KNewStuff can expose Appimage packages, and the user have the option of installing them, all the better.
Furthermore, if Appimage packages were installed ‘via’ Discover, it would enable Discover to keep a list of installed Appimages, and ensure the User could view and manage all installed apps from one place.
LikeLike