Yuzic is a phone client for the music server you already run

A client for servers, not a player for files

Yuzic is a free, open source music player for Navidrome, Jellyfin, Emby, Plex, local files and other Subsonic compatible servers, and the readme is clear that the server is the point. The feature list opens with your music, your way, which is the ability to connect Navidrome, Jellyfin, Emby, Plex, another Subsonic compatible server, or to import files privately from the device itself. That last option matters more than it sounds, because it means the app is usable against a plain folder of music with no server at all, but the design still assumes a library with structure. A complete library means browsing artists, albums, tracks, playlists and genres, with search either on device or through the server, and rating what you play where the server keeps ratings. The server topics on the repository include navidrome, jellyfin and lidarr, and the primary language is TypeScript on top of React Native with Expo, with the web variant hosted on a project page.

Playback features are native rather than bolted on

The second feature line covers native playback, and the list is the sort of thing a client gets right or gets wrong for years. Streaming up to lossless quality, crossfade, replay gain, a ten band equaliser, a sleep timer, playback speed and autoplay. The ten band equaliser is the most concrete of these, since equalisers are usually either absent or a system level feature that a third party app cannot reach, and having one inside the app means it works the same on every device. Replay gain matters for anyone who plays albums, because it is the difference between an album being at a consistent level and the last track being much louder than the rest. Crossfade and playback speed are the two that people discover late and then use daily, and autoplay is a small touch that avoids an interruption at the end of a queue. The distinction the readme draws is between native playback and the rest of the app, and it signals that the audio path was designed rather than inherited from a media framework.

Offline downloads that reconcile when you reconnect

The app works offline, with downloads for songs, albums and playlists, and the important detail is that changes made offline sync when you reconnect. That sentence carries the design. An offline mode that only reads is easy; one that accepts edits while disconnected and reconciles them later is not, because you have to decide what happens when the same rating or playlist was changed in two places. The readme does not describe the conflict rules, which is a gap for anyone who relies on offline editing rather than offline listening, but the claim that offline changes sync on reconnect is the promise to test first. A separate point is where the ratings live. The library feature says you can rate what you play where your server keeps ratings, which means the rating is not a local annotation that you have to reconcile but a property of the server, and the same rating shows up in the server's own interface. For a self hosted library that is the right design, since it survives a phone replacement and stays consistent with the web interface.

Casting covers AirPlay, DLNA and the server jukebox

The play it elsewhere feature covers three different routes, and they are not equivalent. AirPlay on iOS is the native Apple path, so a phone can hand audio to an Apple device or a speaker that supports it. DLNA and UPnP on the network is the open standard route to a renderer anywhere on the local network, which is the option that works with hardware the phone has never heard of. The third is the server's own jukebox, where the server plays the music on the machine it runs on, and the readme hedges it with where available, which is an honest signal that not every server implementation offers it. The three together mean that the phone is a control surface rather than the only output, which is the difference between a phone client and a phone music player. The same list also includes the private by default statement, that optional integrations stay off until you enable them, which is the correct default for an app that talks to a server you own.

The repository is an Expo app with its own architecture linter

The tree tells you more about how this project is run than the readme does. The package manifest names the entry point as the Expo router entry point, and the scripts cover the usual Expo commands for starting, running on Android, running on iOS and running on the web, plus Jest with the Expo preset for unit tests. The end to end tests are run with Maestro, and the scripts show a smoke flow, a common user flows file, a detail flows file, a ratings flow and an onboarding demo, each with its own command, which is a level of end to end coverage that most client applications do not have. There is a directory of custom ESLint rules, a patches directory driven by a postinstall script that runs patch-package and fails the install on error, a plugins directory, a fastlane directory for store release automation, an Expo configuration file for the build service, and a maestro configuration directory. What stands out is the architecture script, which runs a series of checks over the source, including one for dependency cycles, one for unused code, one for provider branches, one for file shape, one for unsafe code, one for shims and one for test only exports, each with a prune variant that can remove what it finds. Writing your own linter for your own architecture rules is unusual, and it says the team treats dependency direction as something to enforce rather than review.

Frequent releases, and the version in the manifest runs ahead of the tags

Yuzic is shipping quickly. The release list shows 2.15.0 on 2026-09-27, 2.16.0 on 2026-09-28 and 2.17.0 on 2026-10-01, three releases in five days, and the last push was on 2026-10-19, with the package manifest already at version 2.17.1, one patch ahead of the newest tag. The readme links the app store listings, the latest release and a Discord server, and the contributing section points at a contributing guide for local setup and checks, the issue tracker for discussing a change, and the chat. The project is GPL-3.0 licensed, which for a client application is a meaningful choice, since it means anyone can fork and ship their own build, and it also means the app store binaries are covered by a licence that requires the source to remain available. For someone evaluating it, the pace is good news for bug fixes and a mild warning about API stability, since a client that changes its internal data layer often is easy to break if you script against it.

Editorial conclusion

Yuzic suits someone who self hosts their music and wants a phone client that treats the server as the source of truth, since browsing, search and ratings all live server side and the local copies are a cache that reconciles on reconnect. It is the wrong choice for a streaming subscription user, since the model assumes you own the library and run the server, and the wrong choice for a desktop listener, since the project describes its targets as iPhone, iPad and Android even though the web build is part of the Expo setup. Verify three things before you install it: which server you run and whether it speaks the Subsonic API that the client expects, since Emby and Plex are listed alongside the Subsonic compatible servers, how your files are organised, because the app relies on the server's own artist, album, genre and playlist structure rather than scanning your disk, and whether the optional integrations, which stay off until you enable them, include anything you would rather not have switched on. The licence is GPL-3.0, the newest release is 2.17.0 from 2026-10-01, and the last push was on 2026-10-19.

Frequently asked questions

Official sources

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