Limusic: a native YouTube Music desktop client in Rust and Tauri

What Limusic replaces, and for whom

YouTube Music in a browser tab works, but it carries a full browser runtime, a persistent tab, and whatever the ad system decides to inject into the audio stream. Limusic is a desktop application that skips all three. According to the README, it "talks directly to YouTube's internal API and plays audio through libmpv: no bundled browser runtime, no backend server, no ads in the audio."

The audience is specific: people who already pay for or use YouTube Music and want it in a native window with OS-level integration. That integration is the part a browser cannot match. The README lists MPRIS on Linux, SMTC on Windows, playback buttons on the Windows taskbar preview, a system tray that keeps playing when the window closes, and optional start-on-login. If you only ever listen at your desk with the tab pinned, none of that changes your day.

The project started as a desktop rebuild of the playback engine behind Metrolist, an Android YouTube Music client, and grew from there. That lineage explains the shape of the feature list: library write actions, day-bucketed history, and queue continuation all read like mobile client features ported to a desktop shell.

The Rust workspace: innertube, player, and a self-hosted relay

The repository is a Cargo workspace, not a single binary crate. The members are crates/innertube, crates/player, crates/listen-protocol, crates/sync-server, and src-tauri. The separation is informative. innertube is the YouTube-facing layer, player wraps libmpv, listen-protocol defines the wire format for synced listening rooms, and sync-server is the relay those rooms run on. src-tauri is the Tauri application that ties them together, with the SvelteKit frontend living under ui/.

The README describes Listen Together as "synced listening rooms over a small self-hosted relay," which means the relay is something you host rather than something the project operates for you. That is a real operational detail: the feature only works if you or someone in the room runs the sync-server component.

One line in the release profile is worth reading closely. The workspace sets lto = "thin", codegen-units = 1, and strip = "symbols", and the comment explains why: the binary ships through AppImage self-update, so "size = every user's download." It also explains why panic stays on unwind, because an abort in the mpv event thread or a tokio task would kill playback for the whole app instead of degrading. That is a considered choice rather than a default left in place.

Installing Limusic and connecting Last.fm

The README points at the GitHub Releases page for downloads and gives a platform table. The AppImage is the self-updating Linux build and bundles libmpv; it needs glibc 2.39 or newer, which the README maps to Ubuntu 24.04+, Debian 13+ and Fedora 40+. On Ubuntu and Debian the .deb installs without self-update and pulls libmpv and webkit2gtk in through apt. On Fedora and RHEL the .rpm requires mpv-libs first:

sudo dnf install mpv-libs

On Arch the README points at the AUR package limusic-bin, which the README says is community-maintained by @xiryuudev and updates through pacman rather than in-app:

yay -S limusic-bin

On macOS, the Apple Silicon .dmg is unsigned, so the first launch needs the quarantine attribute removed:

xattr -dr com.apple.quarantine /Applications/limusic.app

After launching, the first real use is signing in. The README says you can sign in with your YouTube Music account either through in-app Google login or by pasting a cookie, and that several accounts can be held at once with switching between them. Once you are in, the home feed, search, your playlists and liked songs are all available, and write actions such as liking, adding to a playlist and creating playlists are supported.

Last.fm and Discord both live in the title bar next to the window controls. Clicking the Last.fm mark opens a browser tab to approve Limusic, and the README says the connection then persists. Tracks scrobble at the halfway point or four minutes, whichever comes first, which the README notes is Last.fm's own rule. Clicking the mark again shows the account or disconnects it. If you build from source, Last.fm needs your own API credentials, which are not in the repository; the README directs you to last.fm/api/account/create and says to place the key in src-tauri/lastfm.keys.

Where Limusic is the wrong tool

The macOS situation is the clearest limitation. The download table lists a .dmg for Apple Silicon and, for Intel, "none" with a pointer to docs/BUILD-PLATFORMS.md. Intel Mac users are expected to compile the project themselves. The Apple Silicon build is also unsigned, which is why the quarantine command exists; anyone who cannot or will not run that command has no supported path to launching it.

Dependence on YouTube's internal API is the second constraint, and it is structural rather than incidental. Nothing in the README suggests a stability guarantee, and the approach means a server-side change can break search, playback, or library writes without a corresponding change in the client. The project ships frequent patch releases, which is consistent with tracking a moving target, but it also means you should expect to update.

The third case is simpler: if you want a music player for files you own rather than a client for a streaming service, Limusic's Local Music feature will play your files, but the rest of the application is built around the YouTube Music catalogue. A dedicated local library player will fit that job better.

Limusic compared with a browser wrapper

The obvious alternative is a desktop client that wraps the YouTube Music web player in an embedded browser. Those exist and they have one advantage: the web player is the interface Google maintains, so layout and feature changes arrive without the wrapper author doing anything. The cost is that you are running a browser engine and the web player's own ad logic.

Limusic takes the opposite route on both counts. It renders its own SvelteKit interface and fetches from YouTube's internal API directly, which is why the README can claim no bundled browser runtime and no ads in the audio. The trade-off is that every interface feature has to be reimplemented: search, browse, library writes, history, lyrics. The README's feature list is long precisely because none of it comes for free.

A second point of comparison is the playback stack. Limusic uses libmpv for gapless playback with loudness normalization, and the README also offers optional music videos that play where the artwork sits with the same gapless audio behind them. A browser wrapper inherits whatever the web player does. Neither approach is inherently better; they fail in different ways. The wrapper breaks when the page structure changes, and Limusic breaks when the API does.

Licence, upgrade path and maintenance cost

Limusic is licensed GPL-3.0, and the workspace manifest declares the package licence as GPL-3.0-or-later. That matters if you intend to redistribute a modified build, because the copyleft terms travel with the binary. It does not restrict private use. This is a description of the licence text, not legal advice; read the LICENSE file in the repository if the distinction affects you.

Upgrade behaviour depends on which artefact you install, and the README is explicit about the split. The Linux AppImage, the Windows setup.exe and the macOS .dmg self-update. The .deb does not. The .rpm updates through dnf. The AUR package updates through pacman. So the maintenance cost you take on is partly a packaging decision: pick the self-updating builds and you get fixes without thinking about it, pick the package-managed ones and your distribution's tooling stays in charge.

Development activity is visible in the release history. Versions 0.7.0, 0.7.1 and 0.7.2 were published between 2026-09-07 and 2026-09-16, and the last push to the default branch was on 2026-09-17. The workspace version is 0.7.2.

Editorial conclusion

Adopt Limusic if you listen to YouTube Music on Linux or Windows and want a native window rather than a browser tab, and if you accept that the client depends on an undocumented API that can change without notice. Do not adopt it if you need a signed macOS build, an Intel Mac binary, or a client backed by a commercial support agreement. Before committing, check the release page for the current version, confirm your distribution meets the glibc 2.39 floor for the AppImage, and decide whether you want the self-updating build or the package-managed one.

Frequently asked questions

Official sources

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