# Psst: a native Rust Spotify client that needs your own Developer Client ID

> Psst is a cross-platform Spotify client written in Rust with a Druid GUI and no Electron, and since February 2026 it asks you to register your own Spotify Developer app for search, library and playlist features. Here is what it does, how to build it, and where it falls short.

**jpochyla/psst** — Fast and multi-platform Spotify client with native GUI

- Repository: https://github.com/jpochyla/psst
- Stars: 9,482 · Forks: 269
- Language: Rust
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/jpochyla-psst

## What Psst is, and the Spotify Premium requirement it does not hide

Psst is a Spotify client with a native GUI written in Rust, and the README is blunt about its state: it says the project is "still very early in development, lacking in features, stability, and general user experience." That sentence is the most useful thing on the page. It tells you the target audience is not someone replacing the official desktop app today, but someone who wants a small native client, is willing to build from source, and accepts missing pieces.

The hard gate is a Spotify Premium account, which the README states as a note rather than a footnote. If you are on the free tier, the project is not for you regardless of how it is built. The second gate is newer: as of February 2026, Spotify changed developer access, and the README says Psst now requires your own Spotify Developer Client ID for Web API features, meaning search, library and playlists. You register an app at the Spotify Developer Dashboard, set the redirect URI to http://127.0.0.1:8888/login, enable Web API, and enter the Client ID on Psst's sign-in screen. That is a real onboarding step that a packaged music player normally does not ask of you.

Cross-platform means Windows, Linux and macOS, and the release page carries builds for all three, including x86_64 and aarch64 Linux, Debian packages for amd64 and arm64, a macOS .dmg and a Windows .exe. Unofficial builds exist through the AUR and Homebrew, which the README links but does not maintain.

## How psst-core talks to Spotify without an async runtime

The workspace splits into three crates: psst-core, psst-gui and psst-cli. The README describes psst-core as the core library handling the Spotify TCP session, audio file retrieval, decoding, audio output and the playback queue. psst-gui is the Druid application, and psst-cli is an example CLI that plays a track, with credentials configured in the code rather than through a config file.

The README's thanks section is where the architecture gets interesting. It credits librespot, the open source Spotify client library for Rust, and says most of psst-core is directly inspired by its ideas and code, with two stated differences. The first is that Spotify Connect remote control is not supported yet. The second is that Psst is completely synchronous, without tokio or other async runtimes. That second choice shapes everything downstream: network calls and audio work are driven by threads and blocking calls rather than a task scheduler. It keeps the dependency surface smaller and the control flow easier to follow in a debugger, at the cost of the concurrency patterns most Rust networking code now uses.

Druid is the GUI toolkit, and on Linux it has two possible backends, GTK and pure X11, with a Wayland backend described as in the works and GTK as the default. The repository's Cargo.toml sets a dev profile with opt-level 1, and bumps symphonia and libsamplerate to opt-level 2 in dev builds, which suggests decoding and resampling are the parts slow enough to matter during development. The release profile strips symbols, enables LTO and sets codegen-units to 1. On the privacy side, the README states Psst connects only to official Spotify servers and does not call home, caches are local and deletable, and credentials are not stored at all; a re-usable authentication token from Spotify is used instead.

## Installing Psst from a release, a package, or cargo build

The fastest path is a prebuilt binary. GitHub Actions builds and releases new versions when changes land on main, and the README points at the GitHub Releases page with direct links per platform. On Debian or Ubuntu you can take the .deb; on macOS the .dmg; on Windows the .exe. Arch users can use the AUR package psst-git and macOS users the Homebrew cask psst, both described as unofficial.

If you build from source, the README requires the latest Rust stable, at least 1.65.0, on all platforms. On Debian or Ubuntu the dependencies are installed like this:

```bash
sudo apt-get install libssl-dev libgtk-3-dev libcairo2-dev libasound2-dev
```

On RHEL or Fedora the equivalent set uses different package names:

```bash
sudo dnf install openssl-devel gtk3-devel cairo-devel alsa-lib-devel
```

With those in place, a debug build and run are two commands:

```bash
cargo build
cargo run --bin psst-gui
```

The README notes you can append --release to either for a release build. For a macOS .app bundle, it documents cargo install cargo-bundle followed by cargo bundle --release.

After launching, the sign-in screen is where the Client ID goes. Register an app at the Spotify Developer Dashboard with the redirect URI http://127.0.0.1:8888/login, enable Web API, then paste the Client ID into Psst. What you should see is the app connect to Spotify; if search or your library comes back empty, the Client ID or the redirect URI is the first thing to check.

## What is still missing: playlists, retries, device events and caching

The roadmap is unusually honest, and the unchecked boxes are the limitation section you would otherwise have to discover by using the app. Managing playlists is entirely unchecked: follow and unfollow, add and remove tracks, reorder tracks, rename a playlist and playlist folders are all open items. If your workflow depends on editing playlists, Psst cannot do it, and no amount of building will change that today.

Resilience to network errors is also unchecked, described as automatically retrying timed-out requests. Reacting to audio output device events is open too, covering pausing after disconnecting headphones and transferring playback after connecting headphones. Better caching is listed with sub-items about caching as many Web API responses as possible and visualizing cache utilization. Reporting played tracks to Spotify servers is unchecked, which means your listening may not appear in Spotify's own history. Downloading encrypted tracks is unchecked, so offline playback is not there.

The UI section of the roadmap admits more: the current design may be rethought into a two-pane layout, light and dark OS theme detection is not implemented, error states are not robust and lack a retry button, the now-playing highlight can be wrong when the same track appears in several albums or playlists, long album and track lists are not paged or virtualized, there is no album or artist grid, and playback state is not saved. The README's own opening sentence about stability is not modesty; it matches the list.

## Psst compared with ncspot and librespot

The related searches around this project mix several clients, so it is worth separating them. ncspot is a terminal client, and the difference is not cosmetic: ncspot lives in your shell with keyboard-driven navigation, while Psst ships a Druid window with a native GUI on Windows, Linux and macOS. If you work over SSH or want a client inside tmux, a GUI application is the wrong tool, and Psst's own psst-cli is an example rather than a usable front end, since the README says its credentials must be configured in the code.

librespot is the closer comparison, and the README makes the relationship explicit: most of psst-core is directly inspired by librespot's ideas and code. The stated differences are that Psst does not support Spotify Connect remote control yet and that Psst is completely synchronous, without tokio or other async runtimes. librespot is a library and a set of binaries aimed at embedding Spotify playback into other things; Psst is an application with a GUI on top of a core library that borrows from it. If you want to build your own client or run a headless Spotify endpoint, librespot is the layer to start from. If you want a window you can open and click, Psst is the one that ships one.

On the Android question that shows up in search data: nothing in the README, the roadmap or the release table mentions Android. The downloads cover Linux, Debian packages, macOS and Windows only, so treat Android as unsupported rather than planned.

## Maintenance, upgrades and the MIT licence

The last push to the repository was on 2026-08-18, about a month before this writing, and the repository is not archived. The most recent release entry is a rolling continuous release labelled 2026.08.18-3c3621a, tagged 2025-06-28, which reflects the README's statement that GitHub Actions builds and releases new versions when changes are pushed to main. Practically, that means there is no versioned release cadence to plan around: artifacts move with the branch, and a download link always points at the newest build rather than a pinned tag. If you need reproducible installs, pin a commit and build it yourself with cargo build --release instead of trusting the latest link.

Upgrade cost is mostly your own build time plus the occasional breakage from the Spotify side. The February 2026 developer access change is the clearest example: it turned a working sign-in into one that requires your own Client ID, and nothing in the README suggests that requirement will be removed. A Psst upgrade can therefore demand action outside the repository. There is no migration tooling described, and the README does not document rollback, so keep a known-good commit if you depend on the app.

Psst is MIT licensed, which is permissive and places few conditions on reuse and redistribution. That is a statement about the licence text, not legal advice; if you plan to redistribute builds, read LICENSE.md in the repository and the terms attached to the unofficial AUR and Homebrew packages, which are maintained outside the project.

## Conclusion

Psst suits engineers who want a small native Spotify client they can read and build themselves, who already hold a Premium account, and who do not mind registering a Spotify Developer app to get search and library features. It is the wrong choice if you need playlist editing, offline downloads, Spotify Connect remote control or predictable error handling, all of which the README and roadmap still list as unfinished. Before adopting it, verify two things against the current release: that you can complete the sign-in flow with a redirect URI of http://127.0.0.1:8888/login, and that playback works on your audio backend, because the roadmap still lists reacting to audio output device events as an open item.

## FAQ

### What is a lightweight Spotify client for Windows?

Psst is one: it is a native GUI client written in Rust without Electron, and the releases page provides a Windows Psst.exe build. It requires a Spotify Premium account and, for search, library and playlists, your own Spotify Developer Client ID.

### Does Psst work on Android?

The README lists Windows, Linux and macOS as the supported platforms, and the download table covers Linux binaries, Debian packages, macOS and Windows only. Nothing in the repository material mentions an Android build.

### Why does Psst ask for a Spotify Developer Client ID?

The README states that as of February 2026 Spotify changed developer access, and Psst now requires your own Client ID for Web API features: search, library and playlists. You register an app at the Spotify Developer Dashboard with the redirect URI http://127.0.0.1:8888/login, enable Web API, and enter the Client ID on the sign-in screen.

### Can Psst edit playlists or download tracks for offline use?

No. The roadmap lists managing playlists, including follow and unfollow, adding and removing tracks, reordering, renaming and playlist folders, as unchecked, and downloading encrypted tracks is also an open item.

### Does Psst support Spotify Connect remote control?

The README says Spotify Connect remote control is not supported yet, naming it as one of the differences from librespot. Reacting to audio output device events, such as pausing after disconnecting headphones, is also an unchecked roadmap item.

## Sources

- [Issues](https://github.com/jpochyla/psst/issues)
- [jpochyla/psst on GitHub](https://github.com/jpochyla/psst)
- [License: MIT](https://github.com/jpochyla/psst/blob/main/LICENSE)
- [README](https://github.com/jpochyla/psst/blob/main/README.md)
- [Releases](https://github.com/jpochyla/psst/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jpochyla-psst