spotify-qt: A Lightweight Qt Client for Spotify

spotify-qt's Smaller Spotify Client Scope

spotify-qt addresses users who find the official Spotify client too large or too feature-heavy for routine desktop listening. The README describes the project as a "simpler, lighter alternative" and lists fast startup, low resource use, a small file size, portability, and customization among its goals. Those are project goals rather than independently established performance measurements. The README does not publish resource benchmarks or compare application sizes with the official client.

The application does not attempt to reproduce every official Spotify feature. That exclusion is explicit in the project's non-goals, which state that matching the official client's feature set is not intended. This makes spotify-qt a focused choice for users who prioritize a compact Qt interface over broad feature parity. It also means users should not treat missing official-client features as accidental gaps without first checking the project's roadmap, issues, or wiki.

It is an unofficial client, so it should be evaluated separately from Spotify's first-party software. The repository also assigns platform support a wider scope than its tested-platform scope. Any C++17 system with Qt 6 is described as supported, but Linux x64 and macOS arm64 are the platforms regularly tested.

The Separate Client and Premium Playback Dependency

spotify-qt is not presented as a self-contained playback engine. The README says that an actual Spotify client must be running, and it gives librespot as an example. The application can configure that example client from within its interface. This arrangement separates the graphical client from the component that handles Spotify playback, allowing spotify-qt to remain focused on its Qt user experience.

The README does not describe the internal IPC protocol, process discovery behavior, session handling, or exact data flow between spotify-qt and librespot. Those mechanisms should not be inferred from the repository's `src/`, `lib/`, and `cmake/` directory names alone. What can be established is the operational dependency: spotify-qt needs a working Spotify client behind it, and librespot is the named example.

There is a second hard service dependency. The README explicitly says that controlling playback requires Spotify Premium. Browsing or interface access is not clearly separated from playback control in the documentation, so users without Premium should verify their intended workflow rather than assume the application is useful without a subscription. The project also does not provide its own account credentials store, authentication flow, or subscription entitlement handling in the documented setup instructions.

Portable Packages, Builds, and Platform Boundaries

The easiest installation path depends on the operating system. The README lists packages for Arch, NetBSD, FreeBSD, Void Linux, NixOS through `nixpkgs unstable`, openSUSE, Alpine Linux Edge, Fedora through Copr, and Windows through Scoop extras. These entries identify package maintainers separately from the main project. For package problems or stale versions, the README directs users to the relevant package maintainer unless that person also maintains spotify-qt.

Portable binaries are available from the project's latest release page for other Linux distributions using glibc 2.34 or later, macOS 13 or later, and Windows 1809 or later. The release assets are not enumerated in the README, so users must inspect the release page for the artifact matching their architecture. Daily unstable builds are also published through the separate `spotify-qt-nightly` project, but this is a distinct risk choice from a stable release.

The tested combinations are narrower than the declared support range. Linux x64 and macOS arm64 are regularly tested, while other combinations may encounter issues. The repository includes workflow badges for Linux, Windows with MSVC, and macOS, but badge presence alone does not establish every architecture. Platform support should therefore be checked against the release assets, package availability, and known issues rather than inferred from the broad C++17 and Qt 6 statement.

Building spotify-qt and Launching the Stable Branch

For a first source build, use the stable branch rather than the repository's unstable `develop` branch. The documented prerequisites are Qt 6.0 or later with SVG support, CMake 3.16 or later, `make` or `ninja`, `g++`, and `git`. The commands below clone the stable branch, configure a `RelWithDebInfo` build, compile in parallel, and launch the resulting executable.

git clone --branch stable https://github.com/kraxarn/spotify-qt.git
cd spotify-qt

The clone should create a `spotify-qt` directory and check out the stable branch. If command-line build tools are installed through a package manager, that installation is system-specific and the README does not provide one universal package command.

cmake -S . -B build -D CMAKE_BUILD_TYPE=RelWithDebInfo
cmake --build build --parallel

CMake creates the `build` directory, and the second command compiles the project. A successful build should produce `build/spotify-qt` on the documented Unix-like build path. The README does not document separate commands for Windows builds or portable package creation.

./build/spotify-qt

This launches the application. At first use, the separate Spotify-compatible client still needs to be available. The README names librespot and says it can be configured from within spotify-qt. It does not document a particular librespot command, port, configuration file, or spotify-qt account setup sequence.

Trade-offs Against the Official Spotify Client

The official Spotify client is the alternative against which the project positions itself. spotify-qt takes a narrower approach: it supplies a lightweight Qt interface and expects a separate Spotify client to handle the underlying operation.

That separation can help users who specifically want the smaller interface, but it also creates an extra operational dependency. A failure may originate in the external client rather than in spotify-qt, and the README does not provide troubleshooting procedures for diagnosing that boundary. The separate client also needs a compatible operating-system environment of its own.

Feature parity is the decisive trade-off. Someone who wants a customizable desktop front end may accept spotify-qt's narrower scope. Someone who depends on the official client's complete feature set should use the official client instead. Based on the repository's stated non-goals, spotify-qt should not be selected merely because it is a Spotify client. The relevant question is whether its smaller Qt interface and external-client model fit the user's workflow.

Maintenance Signals, Releases, and GPL-3.0 Effects

The repository is not archived. Its last push was on 2026-10-05, showing recent repository activity, but recency alone does not prove stability. The listed stable releases were v4.0.2 on 2026-02-07, v4.0.3 on 2026-03-04, and v4.0.4 on 2026-05-01. Package users may still receive a version governed by their distribution or package maintainer.

The `develop` branch is described as unstable at all times. The stable branch is recommended for normal source builds because it is updated after stable releases with important bug fixes. This creates two upgrade paths. Package users need to follow package-manager updates, while source builders can move between stable releases or deliberately use daily unstable builds. The README does not document upgrade migrations, configuration backups, rollback, or compatibility between releases, so those points remain unverified.

The project is licensed under GPL-3.0. Redistributors and integrators should review the repository's `license` file and comply with the license terms that apply to their distribution. This is an engineering review rather than legal advice. The practical upgrade cost also includes the external Spotify client and any package-specific maintenance, because updating only spotify-qt does not establish compatibility with every separate client version.

Editorial conclusion

Adopt spotify-qt if you want a configurable Qt desktop interface and accept the dependency on another Spotify client. Do not choose it if you need parity with the official application or cannot provide the required backend. Before installing, verify package freshness with its maintainer, confirm that your platform and architecture are tested, and check that the separate client can run on the same system.

Frequently asked questions

Official sources

1. Issues
2. kraxarn/spotify-qt on GitHub
3. License: GPL-3.0
4. README
5. Releases