Rush: an Android lyrics app that fetches, stores and shares song lyrics

The motivation, and what it is actually an app for

Rush is described as an app to search, save and share lyrics like spotify, and the motivation section explains why it exists in a way that says more about the product than the feature list does.

Spotify removed its feature to see and share lyrics from its free tier just to bring it back again. So the author made this app to get and store lyrics for favourite songs from Genius and share them like Spotify, all in Material 3 look. And as an audiophile, this has now become the author's way to listen to complete albums with lyrics without dealing with Genius's UI.

That last sentence is the real specification. This is a companion app for listening to albums, not a search engine for song lyrics. The mental model is a music player that happens to have lyrics, and the share flow is a feature of that, since sharing a lyric is how you tell a friend what you are listening to. The feature list in the repository topics names the sources: genius-api, lyrics-fetcher and lrclib, alongside jetpack-compose, koin and kotlin-android.

So the audience is a person on Android who wants lyrics for the songs they are playing, in an interface that feels like the music apps they already use, without a browser tab open next to the player. The primary language is Kotlin, the licence is GPL-3.0, and the repository is not archived with the last push on 2026-10-14 and releases at 7.1.1 on 2026-10-13, following 7.1.0 in October and 7.0.6 in September.

That release cadence is worth noticing. Three releases in under a month on a 7.x line is the pace of a single developer actively shipping, and it says something about how you should treat the project: it is moving fast, which is good if you want features and a consideration if you want stability.

Where the lyrics come from, and why two sources

The app fetches lyrics from Genius, and the repository topics also name lrclib, which is LrcLib. The inspiration list in the README names LrcLib explicitly, alongside Fastlyrics, SongSync and LyricsPlus, which are the other open-source lyrics apps the author looked at.

Having two sources matters more than it might sound. Genius is a web service with a public API and a web interface designed for humans browsing pages, and the app is described in the motivation as avoiding Genius's UI. LrcLib is a different thing entirely: it is a lyrics database with an API designed for programmatic access and with a focus on synchronised lyrics, the timestamped format known as LRC that a music player can scroll in time with the track.

The repository topics separate the concerns into genius-api and lyrics-fetcher, with lrclib as a separate entry, which suggests the app treats them as distinct sources rather than one fallback for the other. That is a sensible design for an offline-first lyrics app, because the two services have different strengths: one has broad coverage and the metadata to match a song to its lyrics, the other has the synchronised data that makes the in-player display work.

The dependency list adds the other piece. KSoup is the HTML parser, which is what you need to read a page that was designed to be read by a browser, and the Genius API client is the other route. Landscapist and the ColorPicker Compose and MaterialKolor and Kmpalette entries are the image loading and theming libraries, and Zoomable is the pinch-to-zoom component that a lyrics view wants.

The practical point for an adopter is that this app depends on third-party services. The lyrics it shows are fetched from Genius and from LrcLib, so their availability, their rate limits and their terms are part of your experience of the app, and the caching is what keeps it usable when they are not available.

A multiplatform codebase, and what the build layout says

The repository tree shows a Kotlin Multiplatform project rather than a single Android app, and that is the most structural fact about it.

There is an androidApp/ directory, a desktopApp/ directory and an iosApp/ directory, plus a shared/ directory that holds the code common to all three, and an androidLibs/ directory. The screenshots section is split the same way, with Phone screenshots and separate Tablets and Desktop screenshots, so the desktop target is a real user-facing target rather than an experimental branch.

The build tooling is Gradle with Kotlin DSL, with settings.gradle.kts and build.gradle.kts at the root, a gradle/ directory and the gradlew and gradlew.bat wrappers, and a gradle.properties. There is a buildSrc/ equivalent in the tree listing, a spotless/ directory for code formatting, and a devshell.nix with a flake.nix and flake.lock, so there is a Nix development shell for reproducible tooling. The fastlane/ directory holds the release metadata and the phone screenshots used in the store listing, and the badges/ directory holds the README badges.

Dependency injection is Koin, per the repository topics, and the UI is Jetpack Compose. The library list in the README is the usual Kotlin Android set: KSoup for parsing, Landscapist for image loading, ColorPicker Compose and MaterialKolor and Kmpalette for colour, Zoomable for gesture zoom, FileKit for file access, and the RevenueCat Android SDK for the purchase layer.

The RevenueCat dependency deserves a note because it tells you something about the product. Rush has a free tier and a paid tier, with in-app purchases routed through RevenueCat, which is the standard way to handle subscriptions on both Google Play and the App Store with one integration. The Google Play listing in the README is for com.shub39.rush.play, and there is a GitHub releases badge alongside it, so the project is distributed both through the store and as builds you can install yourself.

For a reader deciding whether to trust the codebase, the AGENTS.md, CHANGELOG.md and CONTRIBUTING.md at the top level, plus the Code of Conduct reference in the README, describe a project with normal project hygiene.

Translations through Weblate, and the signing story

Two details in the README are worth a paragraph each, because both are about trust rather than features.

The first is translation. Translations are done via weblate, and the README links the hosted Weblate project for Rush with a widget showing the translation status and a link to the 287x66 status image. Weblate is a translation management platform, and using one means the string catalogue lives in a system where translators work directly on it, the app pulls the translations at build time, and the state of the translation is visible to everyone rather than accumulated as pull requests.

The second is the signing fingerprint. Under a Security heading, the README gives a SHA-256 fingerprint for the signing certificate used for GitHub releases:

0F:E1:B9:F4:4A:4D:B9:7E:C5:09:48:F5:18:9F:6B:43:00:71:6C:C6:D4:84:3F:56:98:D6:14:A2:15:2E:21:88

Publishing that fingerprint in the README is the thing a careful project does, because it lets anyone downloading a release verify the signature against a value that is in version control rather than in a web page that could be replaced. Combined with the GitHub releases link in the badges, it means the sideload path is verifiable.

What the README does not describe is anything about the Google Play listing's data safety, the retention of cached lyrics, or how the app handles the licensing of the lyrics it displays. Lyrics are copyrighted text, and a lyrics app lives or dies on how it handles that, and the visible README is silent on the point. That is a question to raise with the project rather than an accusation, but it is a question an adopter should ask.

Where Rush is the wrong choice

There are three limits, and the first is about depending on someone else's website.

The first is the Genius dependency. The lyrics come from a service the app does not control, fetched either through its API or by parsing its pages with KSoup, and the project's own description of avoiding Genius's UI is an admission that Genius's web pages are not a stable interface. A service that changes its markup can break lyric fetching for users, and a service that changes its terms can affect the app's legality. The LrcLib source reduces the exposure, but does not remove it.

The second is that the cache is what makes it work, and a cache is a thing you have to live with. Lyrics are stored locally, which is what allows the offline album-listening workflow the author describes, and it also means the app holds a copy of copyrighted text on the device. There is no scrub or expiry in the visible documentation, and the fastlane metadata and the shared/ module would be where you would look for it.

The third is scope and shape. This is an application with a user interface, a store listing, a subscription tier and a person behind it, not a library or a component you embed. If you want lyrics in your own app, the useful parts are the lyrics-fetching approach and the sourcing strategy, and you would be writing the rest. If you want an Android lyrics app, the question is whether this one fits, and the answers are: it is Material 3 and Compose, it targets Android with desktop and iOS builds, it is GPL-3.0 so a fork carries that licence, and it is one maintainer's project.

There is a fourth point, smaller but real. The app's differentiation is its presentation, and a Material 3 look that resembles a music player is a matter of taste that ages. The data is the commodity and the interface is the product, and the interface is the part that will need to be maintained.

Editorial conclusion

Adopt Rush if you want a ready-made Android lyrics client with a Material 3 interface, offline caching and a share flow, and you are comfortable with a small project maintained by one person. Do not adopt it as a component of a larger product, since it is an application rather than a library, and note that it depends on Genius and on LrcLib, which means it inherits their availability and their terms. Verify first that the release you install matches the lyrics sources it uses, that the app's data handling of third-party lyric content is acceptable for your jurisdiction, and that the platform you need is one of the three it actually ships for.

Frequently asked questions

Official sources

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