App Center and the Flutter rewrite of the Ubuntu software store

The Ubuntu App Store client and the Flutter decision behind it

App Center is the application store client for Ubuntu, and the repository description is blunt about the technology: an App Store for Ubuntu made with Flutter. The primary language is Dart, and the topics attached to the repository are dart, flutter, snap, store and ubuntu.

That choice is the single most consequential fact about the codebase. A store client is a graphical application that talks to a package backend, renders lists and detail views, and has to stay in step with whatever the system package manager expects. Writing it in Flutter means the interface is a Dart and Flutter application rather than a native toolkit client, with the toolkit and the language toolchain attached to every change.

The consequences are visible elsewhere in the tree. There is a .fvmrc file, which pins a Flutter version manager configuration for the project, and a .metadata file, which is Flutter's own per-project marker. Neither would be present in a project that was not built around that toolchain.

The scope here is the client, not the backend. The snap packaging and the packagekit-session-installer directory in the repository are about how the store talks to the system, not about a new package repository.

A melos monorepo with packages instead of one application

The top level of the tree is not a single Flutter application. It is a monorepo.

The melos.yaml file at the root, alongside a top level pubspec.yaml and pubspec.lock, is the standard marker of a Dart monorepo managed with melos. The packages directory holds the individual Dart packages, which is where the reusable pieces of a Flutter codebase of this size would live rather than being compiled into a single target.

Alongside those there is a scripts directory, a snap directory that holds the packaging definition, and a separate top level directory named packagekit-session-installer. That last name is informative on its own: it points at a component concerned with running install sessions through PackageKit, the system level abstraction that lets a graphical tool ask the distribution to install software with the right privileges and policy. The name indicates the responsibility, and the details of how it does that are not described in the repository documentation.

The build and quality tooling around this matches a project of that shape. There is a codecov.yaml at the root alongside a coverage badge, and a CI workflow referenced by the actions badge points at ci.yaml.

Distribution through the snap-store snap on snapcraft.io

The published artifact is a snap called snap-store, and the project home page is the snapcraft.io page for it. The repository links that page with a badge, which is the convention for pointing users at the install channel rather than at the source.

Publishing through snap means the store client is distributed as a snap itself, so it updates through the same mechanism as other snapped software on the desktop. It also means the store lives inside the sandbox that snaps impose, and that is where the packagekit-session-installer component becomes interesting: a sandboxed application still has to ask the host to perform privileged installs, and the name of that directory is the reminder that this boundary is handled explicitly rather than ignored.

The repository also carries an AGENTS.md, a CLAUDE.md and a .claudeignore file, alongside .agentignore. These are instructions for automated coding agents that live with the project, which is a sign that contributors are expected to work with those tools in the loop.

For a snap based client the release story has two halves that do not match, and that mismatch is worth holding on to.

Tagged releases stuck at alpha while the code keeps moving

The recent release list is the weakest part of this project, and it deserves to be stated plainly rather than smoothed over.

The tags are v0.3.0-alpha from 2023-06-04, v0.2.9-alpha from 2023-02-12 and v0.2.7-alpha from 2023-01-21. Every one carries an alpha suffix. The 0.2.7 tag is annotated in a way that suggests it was the snap-store snap in the preview and candidate channels, with preview and edge to follow.

Against that, the last push was on 2026-10-19 and the repository is not archived. So the code is being worked on while the tags sit three years behind, all of them alpha.

There are two readings and the repository does not settle between them. Either releases moved to the snap channel and the tags stopped being the shipping mechanism, or the tagged line stalled while development continued elsewhere. The repository does not contain a changelog to settle it, and the repository documentation does not mention one. What is certain is that there is no stable numbered tag to pin, and anyone who needs a reproducible artifact should take the published snap rather than a tag.

Translation handled on Weblate under the ubuntu-desktop-translations project

Localisation is not done in the repository. The repository links a translation status badge that points at a Weblate widget for the app-center component of the ubuntu-desktop-translations project, and the contribution link on the same page leads to a Weblate project page rather than to translation files inside the tree.

That arrangement is the usual one for desktop applications shipped by a distribution. Translators work in Weblate, the platform handles the source strings, and the built application pulls the result at package time. It also means the strings for this application do not live in this repository, so a fork that changes user facing text has to account for how it reconnects to that pipeline.

The top level file list supports this picture. There is no separate locale or translation directory at the root, while the repository does carry AUTHORS.md, which is the conventional place to credit contributors, and a CONTRIBUTING.md that the repository documentation points to before anyone raises a change.

The project describes itself as open source and invites community contributions, suggestions and constructive feedback, and asks people to read the contribution guidelines first.

What the repository does not tell you, and what to check instead

The repository documentation is short, and it is short on purpose. It identifies the repository as the code repository for App Center, links the snap, the CI badge, the coverage badge, the licence, the translation status, and points contributors at the contribution guidelines. It does not describe features, does not document configuration, does not list supported package sources, and does not explain how the client is pointed at a particular mirror or architecture.

That thinness is a fact about the documentation rather than about the software. For anyone deciding whether to adopt this project, the useful artefacts are elsewhere in the tree. SECURITY.md is where a vulnerability report belongs, and its presence tells you the project expects security issues to be raised. The CONTRIBUTING.md file defines how to submit work. codecov.yaml shows that coverage is measured and configured, which is how you judge whether a change is covered by tests. The AGENTS.md and CLAUDE.md files describe the conventions that automated contributors are expected to follow.

The gap that matters most in practice is the absence of any documentation of the package sources the store presents to users, or of the behaviour of the install path. If your decision depends on which backends the client supports, that has to be established from the code in packages/ and from the snapcraft listing rather than from the repository documentation.

Editorial conclusion

Adopt App Center if you are building on the Ubuntu desktop and want the store client that ships with the distribution, keeping the Flutter and Dart codebase as the place to make changes. Skip it if you need a stable tagged release you can pin, since the newest tag in the repository is still an alpha from 2023 while the code itself keeps moving. Before you rely on it, install the published snap from snapcraft.io/snap-store rather than building from source, check the contributions and security files in the repository root, and confirm that the packagekit-session-installer component in the tree covers the install path your distribution expects.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. ubuntu/app-center on GitHub