Kreate: a RiMusic fork for YouTube Music on Android

A fork with one stated difference

Kreate is a RiMusic fork with performance in mind, and the project description calls it a multilingual YouTube Music frontend for Android that prioritises performance.

The lineage is the first thing to understand, because it tells you what you are getting. RiMusic is an open source YouTube Music client for Android, and Kreate is a fork of it rather than an independent app. That means the feature set, the playback engine, the YouTube API handling and the interface structure come from upstream, and the fork is where the differences are made.

The difference the project names is performance, and the fork is maintained by a developer who uses it as his daily driver, which is the usual reason a performance fork exists at all. It is worth being clear-eyed about what that claim means, though. The README does not publish benchmark numbers, so there is nothing here to compare against the upstream client, and the honest way to evaluate it is to install both and use them.

The rest of the repository is a substantial Android application. The primary language is Kotlin, the licence is GPL-3.0, the homepage is kreate.knighthat.me, and the project has a documentation site built with mdBook and a blog, both under that domain. There is a Discord community linked from the README.

The last push was on 2026-10-15, and the repository is not archived.

The distribution channels

The installation section is a set of badges, and the set is wider than most Android projects manage, which is a good sign about how the project expects to be used.

There is a GitHub releases link for the latest version, with the download count badge showing the total for the latest release and for all time. There is Obtainium, the tool that tracks a GitHub release and installs it like a package manager, and the Kreate link on Obtainium is configured in detail: the application id me.knighthat.kreate, the repository pointing at knighthat/Kreate, a filter on the release asset name Kreate-release.apk, automatic filtering by architecture, version detection from the release date, and a check on the latest tag.

Then there are the F-Droid style repositories. The package is on F-Droid as me.knighthat.kreate, on OpenApk, and on IzzyOnDroid, and the README carries badges reading the download counts from a F-Droid metrics dashboard for the last month and for all time, plus a yearly download figure from the IzzyOnDroid statistics service.

The practical difference between those channels matters. F-Droid builds from source, so you get a reproducible build from a known commit. The GitHub release and Obtainium paths give you the maintainer's own nightly binary, which is newer and which is where the performance work actually shows up.

The releases themselves are labelled as nightly builds, with tags like v2026.10.06 described as 20261006 with a nightly build note, then v2026.08.20 and v2026.07.10. There is no separate stable channel in that list, which is the single most important fact for anyone deciding how to install it.

Localisation is part of the product, not an afterthought

The second thing that distinguishes this fork from the upstream project is translation, and it is the reason a user might pick Kreate over RiMusic even if they do not care about performance.

The feature list names the languages explicitly: English, Italian, German, Russian, French, Spanish, Czech, Turkish, Romanian and more, with an invitation for contributions in other languages. The README carries a Crowdin localisation progress badge, and the translation platform is at translate.kreate.knighthat.me, with the crowdin.yml file in the repository root holding the configuration.

Using Crowdin rather than a GitHub-based translation workflow is a deliberate choice with practical consequences. Contributors do not need to edit the source strings, they work in a dedicated interface, and the platform tracks progress per language, which is what the badge reports. The downside is that the strings live in a separate system from the code, so a new string added in the app is not immediately translatable until it is pushed to Crowdin.

For an end user, the practical benefit is a client that is actually usable in their language rather than a partially translated one. A music player that is half translated is worse than one that is not translated at all, because every label takes an extra tap to work out. Nine named languages with a translation platform behind them is a meaningful floor.

The documentation site and the blog live at the same domain as the app's homepage, and the README links both, so the project treats user-facing writing as part of the deliverable rather than as something to add later.

UI Mode, and why the classic look is still there

The third feature in the list is UI Mode, and it is a small feature that carries a lot of history.

UI Mode lets you switch from the RiMusic style to the classic ViMusic style, and back. Keeping both means the fork does not force a single aesthetic on its users.

That is a real quality-of-life decision for anyone who has been using a music client for years. Interface preferences are sticky in a way that most preferences are not, because a music player is something you open many times a day and use without looking at it. The rest of the feature list calls the designs friendly, which is a subjective word, but the design freedom in the feature list is the point: friendly designs is listed as a feature of its own, right after multilingual support.

The project also publishes a banner image under assets/design, and the README header uses it, so the visual identity is part of the repository rather than something bolted on at release time.

Everything else in the feature list is inherited from RiMusic, and that inheritance is the honest way to think about the scope here. This is not a new music player with a small feature set. It is a large, capable client with a different performance profile, more translations and a switch to put the old interface back.

The Gradle project layout

The repository root shows a modern Android project with a multi-module Gradle setup, and the layout is the clearest description of how large this is.

There is composeApp/ for the application module, modules/ for the shared feature modules, and extensions/ for what are presumably the extension points the app exposes. The Gradle files are the Kotlin DSL versions, build.gradle.kts and settings.gradle.kts, with gradle.properties holding the project properties, and both gradlew and gradlew.bat for the wrapper, which is the standard way to pin the Gradle version per project.

The build tooling is fairly modern for an Android project. The.kotlin/ directory is the Kotlin build cache, and the presence of the.gitmodules file means there are Git submodules in the build, which is common in projects that pull in generated code or shared tooling. scripts/ holds helper scripts, assets/ holds the images used in the README and the store listings, and fastlane/ is set up for the store listings.

The.github/ directory holds the workflows. The.aiexclude and.noai files at the root are the unusual ones, and they are worth a look before you contribute, because they are an explicit statement about how the project treats AI-generated contributions, and a project that publishes such a file is making a deliberate policy choice rather than leaving it implicit.

Maintenance state and the branch you land on

The default branch is chores/update-contributors, which tells you something specific about how this repository is worked on. It is a maintenance branch, not the development branch, so cloning the repository and building the default branch gives you the state of the contributor list update rather than the state of the code.

That is a small thing, but it is the kind of detail that costs a new contributor an afternoon, and it is also a sign of a project that automates the routine parts of its maintenance rather than doing them by hand.

The release history is the nightly line: v2026.07.10 on 2026-07-10, v2026.08.20 on 2026-08-20 and v2026.10.06 on 2026-10-06, each described as a nightly build. The last push was on 2026-10-15, so the tree is ahead of the newest tag, which is what you would expect from a project that builds continuously rather than cutting a release per change.

The practical consequence is that there is no stable channel to point a family member at. If you want a known-good version, the F-Droid and IzzyOnDroid builds are the ones built from a source commit rather than from the maintainer's nightly binary, and that distinction is the one to keep in mind when someone reports a problem: the version numbers in the two channels will not match.

For a project of this size and this activity, the governance is light. The licence is GPL-3.0, the project runs a Discord, and the localisation is handled through Crowdin rather than through maintainers triaging translation pull requests.

Editorial conclusion

Adopt Kreate if you want the RiMusic feature set on Android with an emphasis on responsiveness or the option of the classic ViMusic interface. Do not adopt it expecting a stable release channel, because the tagged builds are labelled nightly builds and the default branch is a maintenance branch, so a fork is the safer route for people who need a known-good version. Before you start, pick the distribution channel that matches how you update apps, and read the AI usage policy files in the repository, since the project publishes them explicitly and that is unusual enough to check before you contribute.

Frequently asked questions

Official sources

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