AppCenter: the pay-what-you-want store for elementary OS

A store for one desktop, with a pricing model attached

AppCenter is described as an open, pay-what-you-want app store for indie developers, and the repository description calls it a pay-what-you-can app store for elementary OS. The primary language is Vala, the licence is GPL-3.0, and the homepage points at elementary.io.

Two things follow from the description. The first is that this is a store for a specific desktop rather than a general package manager, and it is described as the store for elementary OS. The second is the pricing model. The applications in it are not all free, and a pay-what-you-want model means the store handles payment for the developers rather than treating every application as zero cost.

The repository topics support both readings. Alongside appstream, flatpak, gtk and gtk4 there is packagekit, which is the abstract interface a desktop uses to talk to a package system, and stripe, which points to the payment side of the model. The readme itself is brief, and the depth is in the build rather than in the prose, so the rest of this article is about what the code and the build tell you.

For a user, the interesting property is that the store is part of the operating system rather than a separate download, and for a developer it is a worked example of a Flatpak and AppStream client written in a modern GTK stack.

Vala, GTK4 and the elementary libraries

The implementation choices are the interesting part of a desktop application written in Vala.

The top level of the repository is small and conventional for a GNOME style project: a src directory holding the code, a data directory with the application data and the screenshot used in the readme, a po directory for translations, a vapi directory for the Vala bindings, a test directory, a meson.build file and meson_options.txt, and a COPYING file carrying the GPL-3 licence. There is also a BACKERS.md, which is a hint about how the project is funded and who it is for.

The dependency list tells you the stack in detail. The user interface layer is GTK 4 with libadwaita, the GNOME style library, and libgranite for the elementary widgets, with libportal and libportal-gtk4 for the desktop portal integration that a sandboxed application needs. The packaging side is libflatpak, so the store's job is to install and manage Flatpak applications, and libappstream for the metadata catalogue that describes them.

Underneath sit the pieces a modern desktop application needs: libdbus for the service bus, libpolkit-gobject for authorisation, libgee, the collection library for the Vala side, libsoup for HTTP, and libjson-glib and libxml2 for the metadata formats that AppStream uses.

That is a coherent stack, and it is also the reason this application is not portable to another desktop without work. The portal calls, the adwaita widgets and the Granite components are all elementary and GNOME specific.

The dependency list is the platform requirement in full

The build dependencies are listed in full in the readme, and they are worth reproducing because they set the floor for anyone who wants to build it.

* gettext
* libadwaita-1-dev (>= 1.4)
* libappstream-dev (>= 1.0.0)
* libdbus-1-dev
* libflatpak-dev (>= 1.0.7)
* libgee-0.8-dev
* libgranite-7-dev (>=7.7.0)
* libgtk-4-dev (>=4.10)
* libjson-glib-dev
* libpolkit-gobject-1-dev
* libportal-dev
* libportal-gtk4-dev
* libsoup-3.0-dev
* libxml2-dev
* libxml2-utils
* meson
* sassc
* valac (>= 0.26)

Eighteen packages, and the version floors are not incidental. libadwaita 1.4 is the version where the widgets this application uses became available, libgtk 4.10 is the floor for the GTK4 features it relies on, libflatpak 1.0.7 and libappstream 1.0.0 are the versions at which the store's core functionality settled, and valac 0.26 is the oldest Vala compiler that can build the code.

The two development tools in the list are meson for the build system and sassc for compiling the stylesheets, and gettext is there for the translation workflow that the po directory and the translation status badge in the readme reflect.

Building and installing with Meson and Ninja

The build is a Meson project, and the instructions are short.

You configure the build environment with meson build, then change into the build directory and run ninja.

    meson build --prefix=/usr
    cd build
    ninja

The prefix of /usr is what an installed system copy expects, and it is a useful clue about the intended target: this application is packaged by elementary into the operating system rather than installed into a user's home directory by a script.

Installation follows the same build system.

    ninja install
    io.elementary.appcenter --gapplication-replace

The application identifier, io.elementary.appcenter, is used both to launch it and as the D-Bus well known name, and the gapplication-replace flag is what lets a freshly installed copy take over the bus name from a running one. That detail matters when you are iterating on the code, because without it the new build refuses to start and the old instance keeps running.

For a developer working on this, the workflow is the standard Meson one: edit, ninja, install, relaunch. There is no separate packaging step described in the readme, because the distribution packaging is expected to happen in the elementary build system.

Debugging messages and local AppStream metadata

The debugging section gives two techniques, and the second one is the more interesting for a developer who is building an application to be listed.

The first is the standard GLib mechanism, with the documentation pointing at the GLib running documentation, so the whole logging stack can be turned up.

    G_MESSAGES_DEBUG=all io.elementary.appcenter

The second is a command line option to load and preview a local AppStream XML metadata file. The documentation says your local metadata will show up in the featured banner and will also be searchable, and that metadata loaded this way will have a (local) suffix in its name.

    io.elementary.appcenter --load-local /path/to/file.appdata.xml

That option is how someone develops an app for the store. You write the AppStream metadata that describes your application, point the store at the file, and see your entry in the catalogue, in the featured banner and in search, with a marker that shows it is not the published version. The feature banner placement is a nice touch, because it is the difference between an entry that exists and an entry that gets seen.

The metadata itself is XML, and the appdata.xml file name follows the AppStream convention, which is also why libappstream and the XML libraries appear in the dependency list.

Where AppCenter is the wrong tool

Four limits, and the first is about distribution.

This is a store for elementary OS. It assumes the Flatpak runtime and the desktop portal stack that elementary provides, it is installed into /usr by the system, and its releases are versioned alongside the operating system. A team that wants an app store for a different distribution is not going to reuse this code, because the parts that matter, the portal integration, the polkit authorisation, the adwaita and Granite user interface and the elementary payment channel, are all specific to that desktop.

The second is the package format. The store installs Flatpak applications, and there is no sign of a path for distributing a Debian package or an AppImage through it. A user whose platform is not Flatpak first is not served by this application at all, and the reason is visible in the dependency list rather than hidden.

The third is the payment model. A pay-what-you-want store needs a payment provider, and the repository topics name Stripe. That is an integration with a commercial service, with its own account requirements and its own operational cost, and a project that wants to distribute free software is going to find that path less interesting than a plain repository of Flatpaks.

The fourth is the build environment. Eighteen development packages with version floors, a Vala compiler at 0.26 or newer, and Meson and Ninja make this a build you need a Linux workstation with the GNOME and elementary stack installed. There is no indication in the readme of a containerised build, and that is the practical obstacle for a contributor who does not already run a GNOME development environment.

Licence, releases and the state of the repository

The licence is GPL-3.0, carried in the COPYING file at the root of the repository, so the code can be used, modified and redistributed with the notice kept. This is not legal advice, and the readme does not discuss the licences of the applications the store distributes, which are their own business.

The release history is steady and follows the operating system's cadence rather than a fast independent cycle. Version 8.3.1 was released on 2025-09-20, 8.3.2 on 2026-02-04 and 8.4.0 on 2026-03-31. The last push to the default branch was on 2026-10-19, so the work is current even though the most recent tagged release is from March 2026, which is the normal pattern for an application that is packaged into a distribution and released with it.

The internationalisation is taken seriously. The readme opens with a translation status badge pointing at the elementary translation platform, and the repository has a po directory, a gettext dependency and a sassc dependency for the stylesheets, which together mean the interface is translated by a community pipeline rather than by the maintainers alone.

The BACKERS.md file is a signal about the project's shape as well. A store that takes payments for other people's applications has a direct relationship with its users, and the combination of a funding page, a translation programme and a hacktoberfest topic suggests a project that expects its contributors to arrive through community events rather than through an internal team.

The practical advice for anyone reading the source is to start at the src directory, then at the meson.build file to see how the pieces are wired, and to use the load-local option to see the store working against an application you control.

Editorial conclusion

AppCenter is the right reference for a developer writing a GTK4 and libadwaita application in Vala, and it is the right application for a user of elementary OS who wants to install Flatpak apps and support the developers of the ones they use. It is the wrong starting point for a team building a store for a different distribution, and the wrong dependency for an application that needs to install non-Flatpak packages. Before adopting, read the build instructions and confirm the eighteen development packages are available in your distribution, and check whether the pay-what-you-want payment path, which the repository topics point to with Stripe, is something you want to support at all.

Frequently asked questions

Official sources

1. elementary/appcenter on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases