Nix Software Center: a GTK4 app store for Nix packages

An app store for a system that was built to avoid app stores

The description calls it a simple gtk4 and libadwaita software center to easily install and manage nix packages. The README phrases it as a graphical app store for Nix built with libadwaita, GTK4 and Relm4, and heavily inspired by GNOME Software.

That inspiration is the design brief. GNOME Software is what most Linux users picture when they hear app store, with a search field, a grid of package icons, and a details view. Nix Software Center aims to put that familiar surface on top of a package manager whose entire selling point is that you do not install things by clicking them.

So the interesting tension is real, and the project resolves it by offering two destinations rather than one. The feature list separates installing packages to configuration.nix from installing packages with nix profile or nix-env. The first route is declarative, so the change survives a rebuild and shows up in your configuration. The second route is imperative and immediate, so the program is usable on a machine you do not want to restructure.

The audience is Nix and NixOS users, and by extension SnowflakeOS users given the nix-data dependency, who want a GUI for search and updates without giving up the command line for anything delicate.

Two installation destinations, and they behave differently

The first feature is installing packages to configuration.nix, and the README notes that flakes support can be enabled in the preferences menu. This is the path that keeps your system declarative.

The second is installing packages with nix profile or nix-env. These act on the current user environment rather than editing a system configuration file, so the change is immediate and does not require a rebuild.

The distinction is not cosmetic. A package written into configuration.nix is reproducible, reviewable in a diff, and restored when you rebuild the system. A package in a nix profile is convenient and disposable, and it can drift away from what your configuration says.

Two more features round out the list: showing updates for all installed packages, and searching for packages. The updates view is where a GUI earns its keep on a declarative system, since the usual workflow is to notice a new upstream version and then go and edit a file by hand.

The last feature is launching applications without installing them, through nix-shell and nix run. That gives you a way to try a package from the search results before committing it to either configuration.nix or your profile.

Four ways to install it, depending on how your system is set up

The README documents four installation routes, and which one applies to you depends on whether you use flakes and whether you are on NixOS.

On a flakes enabled system, a single run needs no installation at all.

nix run github:snowfallorg/nix-software-center

On a system without flakes enabled, the same run needs the experimental features turned on explicitly.

nix --extra-experimental-features "nix-command flakes" run github:snowfallorg/nix-software-center

For a per-user install, the profile route is the shortest command in the document.

nix profile install github:snowfallorg/nix-software-center

The nix-env route clones the repository first and installs from the checkout.

git clone https://github.com/snowfallorg/nix-software-center
nix-env -f nix-software-center -i nix-software-center

For NixOS users with flakes, the README shows adding the project as a flake input and pulling the package into systemPackages.

{
  inputs = {
    # other inputs
    nix-software-center.url = "github:snowfallorg/nix-software-center";
# rest of flake.nix

The matching configuration.nix entry follows the same pattern, adding the package to environment.systemPackages.

environment.systemPackages = with pkgs; [
    inputs.nix-software-center.packages.${system}.nix-software-center
    # rest of your packages
];

The NixOS configuration route pins a revision and a hash

For NixOS users on the unstable channel or any version after 22.11, the README gives a configuration.nix snippet that fetches the project directly from GitHub with a pinned revision and a hash.

{ config, pkgs, lib, ... }:
let
  nix-software-center = import (pkgs.fetchFromGitHub {
    owner = "snowfallorg";
    repo = "nix-software-center";
    rev = "0.1.2";
    sha256 = "xiqF1mP8wFubdsAQ1BmfjzCgOD3YZf7EGWl9i69FTls=";
  }) {};
in
...

Two details here carry weight. The revision is 0.1.2, which matches the version in the crate manifest, so the pinned source and the published crate are the same code. The sha256 value is the standard Nix hash that makes the fetch verifiable, and it will change with every new revision, which means a bump needs a new hash.

The README also warns about a rough edge that applies to any method other than the flake one: when rebuilding, you might be prompted to authenticate twice in a row by pkexec. That is a small thing to read once and an annoying thing to discover mid-rebuild, so it is worth knowing that it comes from the privilege escalation the write to configuration.nix needs.

The stack is Relm4 on GTK4, with a helper binary alongside it

The dependency list in the crate manifest tells you what kind of application this is. Relm4 at version 0.6 with the libadwaita and macros features provides the component model, and libadwaita is pulled in at 0.4 with the v1_2 and gtk_v4_6 features, with gtk4 itself at 0.6 on v4_6. The UI is built with a declarative Rust pattern rather than with GTK's C style callbacks, and the toolkit underneath is the current GTK4 with libadwaita for the adaptive styling that makes the app look like a modern GNOME application.

Alongside the interface crates, the manifest shows the machinery behind the features. nix-editor at 0.3.0 and nix-data, pulled from the snowflakelinux nix-data repository, handle the Nix side. sqlx with the sqlite feature provides a local database, which is where search results and package metadata are cached. tracker 0.2 provides desktop search indexing. tokio with the process feature is there for the asynchronous work of running Nix commands, and reqwest with blocking fetches remote metadata.

The Rust workspace lists two members, the main package and a directory called nsc-helper, which suggests a separate privileged helper binary alongside the graphical application. The repository also carries a meson.build and a meson_options.txt next to the Cargo files, a po directory for translations, and a default.nix alongside flake.nix, so the build and packaging story supports both Cargo and Meson users.

Logging is the first thing to try when a package does not install

The README includes a debugging section, and it is the only diagnostic instruction in the document.

RUST_LOG=nix_software_center=trace nix-software-center

Setting RUST_LOG to the crate name with the trace level turns on detailed logging for the nix_software_center target and then launches the binary. Since the application runs Nix commands on your behalf and reports back what happened, this is where you look when a package fails to install, when the configuration file edit does not appear, or when the update list looks wrong.

The crate manifest also includes pretty_env_logger, which is what makes that environment variable work, and the log crate for the messages themselves.

It is worth noting what is absent. There is no troubleshooting section covering failed searches, no notes about database corruption or a way to reset the local cache, and no description of what happens when a package in configuration.nix has been edited by hand and conflicts with what the app wants to write. The README is a short document, so treat the trace log as the primary tool rather than an afterthought.

GPLv3 for the code, CC-BY and CC0 for the icons

The project is GPL-3.0, with the licence badge in the README linking to the GNU GPLv3 text, and the LICENSE file in the repository root.

The icon assets carry their own terms, and the README is specific about which is which. Some icons in data/icons contain assets from the NixOS logo and are licensed under a CC-BY licence, while others contain assets from GNOME Software and are licensed under CC0-1.0. That second point is worth noting because the app is heavily inspired by GNOME Software, and the icon reuse is credited accordingly.

For anyone packaging the application, the practical note is that the icon directory carries a mix of licences alongside the GPLv3 code, so a redistribution needs to keep the attribution for the CC-BY assets rather than treating the whole icon set as one thing.

On maintenance, the picture is modest and should be stated plainly. There are no GitHub releases, the crate version is 0.1.2, and the last push to the repository was on 2026-04-07. That date is more than six months before now, so the feature set should be taken as what it was in April rather than as a moving target. What the repository shows is a small working application that has not been touched since the spring.

Editorial conclusion

Nix Software Center suits anyone who moved to Nix for reproducibility but kept coming back to a graphical app store, since it searches packages, shows updates for everything installed and can write a package straight into configuration.nix for a declarative result. It does not suit someone who wants to keep their system defined only by a flake, because the app edits configuration.nix, and it does not suit a user who expects current upstream releases, since the crate version in the repository is 0.1.2, there are no GitHub releases and the last push was on 2026-04-07. Before you install it, decide whether you want the package added to configuration.nix or to a nix profile, read the note about pkexec prompting twice during a rebuild, and if you are on a flakes setup, enable flakes support in the preferences menu first so the two paths do not conflict.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. snowfallorg/nix-software-center on GitHub