YumaPlayer unifies two streaming libraries the services will not

One player for two services and your own files

YumaPlayer is an Android music player that combines the library and recommendation features of two major streaming services with local playback of lossless files. The pitch in the README is a specific combination: one service's interface and discovery behaviour, the other's library, and high resolution audio alongside both.

The problem it addresses is real for a certain kind of listener. People who use more than one service end up with their listening split across applications that do not know about each other, and anyone who also keeps a collection of files has a third place to look. A client that presents all of it as one library is solving a genuine annoyance.

What it is not is an official product. This is an independent client, unaffiliated with either service, and everything below should be read with that in mind.

The audience is narrow and identifiable: Android users with accounts on both services, an interest in audio quality, and a willingness to run software from outside an application store.

An unusually explicit lineage

The README does something uncommon and creditable: it names where the project came from, in detail.

It describes itself as a comprehensive rebuild of one existing player, with foundations taken from two others, and cites three further projects as sources of specific ideas: queue mechanics from one, the integration pipeline for one streaming service from another, and the lossless audio architecture from a third.

Six named predecessors is more attribution than most forks manage, and it matters for two reasons. It tells a prospective user that the difficult parts, the service integrations and the audio path, have lineage rather than being written from scratch by one person. And it sits correctly with the licence, since the project is published under version 3 of the GPL, which is what inheriting from copyleft predecessors requires.

On top of that base the project claims its own contributions: a modular architecture of thirteen modules, a named in-house design system, and hardware-accelerated gesture physics. The repository tree supports the modularity claim, with separate modules visible for the application, a core, a canvas component, the lossless audio handling and a scrobbling integration, alongside shared build logic.

The privacy position is specific rather than decorative

For an application asking for accounts on two services, the security description carries weight, and this one is unusually concrete.

The README states there are no subscriptions, no advertisements, and no telemetry, crash reporting or third-party trackers of any kind. Credentials are stated to live exclusively on the device, encrypted with a named authenticated encryption scheme through a well-regarded cryptography library rather than a hand-rolled scheme.

Naming both the algorithm and the library is the part that separates this from a generic reassurance. Authenticated encryption is the correct choice for stored credentials, and using an established library rather than assembling primitives is the decision that most often goes wrong in applications of this kind.

A privacy document sits in the repository as a separate file, which is where the detail belongs, and the absence of crash reporting is worth noticing as a real trade rather than only a virtue: a project with no crash telemetry is one where the maintainer learns about failures only when someone reports them.

The build tooling suggests a project run with some discipline, with static analysis and lint configuration checked in alongside the Gradle build.

Installing it means going outside the store

There is no store listing described here. Distribution runs through the project's own releases, and the related search terms people use confirm the pattern: the artifact is an application package downloaded and installed directly.

That has consequences a reader should weigh rather than skip. Installation requires enabling installation from outside the store, which is a device-wide posture change. No store review sits between the developer and your phone. Updates arrive through the application's own update mechanism, which the recent release notes list as a feature, rather than through the platform's update path.

None of that is unusual for open-source Android software and all of it is a meaningfully different trust arrangement from installing something from a store. The counterweight is that the source is published under a copyleft licence, so the code can be read and built independently, which is a stronger form of verification than store review when someone actually does it.

The platform requirement is Android 8.0 or newer, which is permissive and covers a wide range of devices.

Version numbering says the rest: the most recent release is a third beta of version 1.2.0, published on 2026-09-12, with the last push on 2026-09-15.

What the recent release actually worked on

The changelog for that beta is a useful signal because of what it concentrates on: playback latency, reliability of synchronised lyrics, library synchronisation across both services in a dual mode, a background video engine, and in-app updates.

Those are the unglamorous problems of a music client rather than new features, and playback latency in particular is the thing users feel without being able to name. A release described as stabilisation, playback performance and architecture is what a project looks like when it has stopped adding surface and started making the existing surface work.

The library synchronisation item is the most technically interesting, described as independent source flags with a database migration behind it. Keeping track of whether a track was liked on one service, the other, or both, rather than collapsing them into a single state, is the correct model and it is the kind of thing that is painful to retrofit. Doing it as a migration rather than a reset suggests existing users were considered.

Elsewhere the feature set leans visual: layered synchronised lyrics, a queue presented as paired sheets with haptic feedback, immersive artist imagery with a morphing collapse, and a glass-style aesthetic throughout. That is a lot of interface work, and screenshots in the repository carry the argument better than a list can.

The risk the README does not discuss

One consideration is absent from the README and belongs in any honest assessment: this is an unofficial client that signs in to commercial streaming accounts, and the repository does not address how either service's terms treat third-party clients.

That silence is the thing to notice. Terms for consumer streaming services commonly restrict access to official applications, and the consequences of using something else fall on the account holder rather than on the developer. Anyone considering this should read the terms attached to their own subscriptions and decide knowingly, because the project cannot make that decision for them and does not claim to.

A second, related point is structural rather than a defect. However carefully credentials are encrypted at rest, entering streaming account details into third-party software extends trust to that software and to whoever builds it. The mitigations here are genuine, and the residual exposure is inherent to the category.

Beyond that, the ordinary limitations apply. The current release is a beta. The interface language is English with a Russian translation, so community discussion may not be in your language. And an independent client tracking two services it does not control inherits the risk that either can change something and break it, which is the same fragility any unofficial integration carries.

The official applications are the alternative

The alternative is what nearly everyone uses: each service's own application, plus something else for local files.

The difference is support against unification. Official clients are maintained by the companies whose services they access, distributed through the store, reviewed, updated automatically, and cannot put your account at risk by existing. They also keep your listening in separate silos, carry advertising or subscription tiers, collect usage data, and give you no say over the interface.

YumaPlayer offers the combination those applications will never provide, since neither company has any reason to present the other's library. It adds lossless local playback in the same place, removes advertising and telemetry, and gives the interface work a level of attention a general-purpose client does not.

The decision is mostly about risk tolerance. If your accounts matter to you and the inconvenience of switching applications is merely irritating, the official clients are the correct answer and this is not worth the exposure. If you already keep music in several places, care about audio quality, and are comfortable running open-source software you could inspect and build yourself, this is a thoughtfully built attempt at the unified client that does not otherwise exist.

Editorial conclusion

YumaPlayer suits an Android listener whose music is already split across two services and a local collection, who cares about playback quality, and who is comfortable installing and if necessary building open-source software from outside an application store. Stay with the official clients if your accounts matter more than the inconvenience of switching between them, since those cannot put an account at risk by existing. Read your own subscription terms regarding third-party clients before signing in, because the repository does not address how either service treats them and the consequences fall on the account holder, and treat the current build as a beta, since the most recent release is a third beta of version 1.2.0.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. MuwMx/YumaPlayer on GitHub
4. README
5. Releases