Hyperion: a native Android YouTube front-end built with Kotlin Multiplatform

A YouTube client that carries its own api and ktor-brotli modules

Hyperion is described as a modern alternate YouTube front-end for Android, and the repository layout shows that it is not a single Android app module. Top-level entries include api/, common/, desktop/, android/, ktor-brotli/, build-logic/, resources/ and shared Gradle files such as settings.gradle.kts and gradle.properties. The declared topics back that up: kotlin, kotlin-android, kotlin-multiplatform, kotlin-coroutines, media3, jetpack-compose and youtube-api in one list.

That combination points to a project where the interface layer and the API layer are separate pieces of code, with the multiplatform arrangement allowing a desktop target to exist alongside the mobile one. The api/ directory and the ktor-brotli/ module in particular suggest the request layer, including compressed transfer handling, lives in the project rather than being borrowed from a separate server.

The interface is built with Jetpack Compose, per the topic list, and media3 handles media playback inside the app. The practical consequence for a user is that the whole client runs locally on the device. There is no separate backend service that Hyperion depends on, which is the structural difference between this project and the browser-based YouTube front-ends that require a companion API instance to be running somewhere else.

Translation is handled as a first-class part of the build rather than a side task. A crowdin.yml file at the root, plus a Crowdin project link, and a resources/ directory indicate that strings are managed externally and pulled into the app, which is why the feature list can advertise multi language support while new strings are still being filled in.

Ad-free playback plus two separate third-party data sources

The feature list is short and specific. Hyperion is ad-free, it integrates SponsorBlock for skipping sponsor segments, and it returns YouTube Dislikes using the Return YouTube Dislikes service. Each of those addresses a different complaint about watching on the official app, and the acknowledgements section credits SponsorBlock and the Return YouTube Dislikes project by name, which is the honest way to describe where the data comes from.

There is a boundary worth noticing. Return YouTube Dislikes and SponsorBlock are external services that feed Hyperion, so their availability and their data are outside this repository. If either upstream service changes its behaviour or goes away, the corresponding Hyperion feature changes with it. The client can be ad-free without any external help; the dislike counts and the segment skipping cannot.

Beyond those two, the list covers download videos and picture in picture. Picture in picture is the feature most likely to matter daily for a phone user, since it lets playback continue in a small window over other apps. Downloads, likewise, address a case that the official client handles awkwardly, and it is the one capability here that stores media on the device, which raises questions about storage and about what the app does with files it has fetched.

Two entries sit in a more to come list rather than in the shipped set: Google account login and custom themes. Neither is available yet, so treat the login item as an open question for anyone who wants to carry subscriptions across devices.

Dynamic color and a theme that can follow the system

Appearance is handled with two separate mechanisms, and the feature list spells out the difference. Dynamic color pulls its palette from the device wallpaper, which is the Material You approach on newer Android versions. Separately, the app offers a dark and light theme with the option to follow the system color mode or override it.

The interaction between the two is where the design decision sits. Dynamic color only produces a meaningful result on a device whose wallpaper-derived palette is available, which in practice means a recent Android release, while the app's stated minimum is Android 5.0 API level 21. On an old device the wallpaper palette will not exist, so the explicit dark and light choice is the one that still works. The README does not describe any fallback behaviour between the two systems, and that is worth checking on your own device before settling on either.

Custom themes are on the more to come list, so the theming story for now is wallpaper-derived palette plus a manual light or dark switch. Anyone expecting full control over typography, shapes or per-app color sources will not find it in the current feature set.

One small entry in the list appears with a stray non-Latin character in front of it, a multi language marker in Chinese. It reads as a leftover from the translation workflow rather than a functional item, which is consistent with the Crowdin based translation setup described earlier.

Installing means sideloading a nightly build from the workflow artifacts

There is no store listing and no stable package, and the project is explicit about that. The installation section says bugs are to be expected at this state of development, states that the minimum supported Android version is Android 5.0 API level 21, and points to a nightly build rather than a release page.

The download location is a workflow artifact link rather than a release asset, at the nightly.link address for the build-debug workflow on the main branch, ending in app-debug.zip. The name says what it is: a debug variant produced by a continuous integration run, not a signed and versioned release. On a phone, you would fetch that archive, extract the APK and install it yourself, allowing installation from outside the Play Store if your device is set up for that.

The project states that GitHub releases will be added once Hyperion is in a more stable state. That is the clearest signal available about how the project intends to distribute itself later, and until then the nightly artifact is the only documented path to running the app.

For anyone who wants to build from source instead, the repository contains gradlew and gradlew.bat alongside the Gradle project files, plus a build-logic/ directory for the build convention setup. The README does not give a build command or list the required Android Studio version, so the exact invocation is left to the reader who already works with Gradle multiplatform projects.

The project status note sets expectations honestly

The most consequential paragraph in the project notes is not in the feature list. Under project status, the maintainer writes that because of personal life, college and work, they are not able to focus on Hyperion as hoped, that it is not abandoned, and that development will take longer than usual. Contributions are described as always welcome and encouraged.

That statement does two things. It rules out the word abandoned, and it sets a slower pace for the roadmap items still sitting in the more to come list, including Google account login and custom themes. If you are waiting for account login before you switch, the wait is as long as the maintainer's other commitments.

The repository was last pushed on 2026-10-17, so code is still moving in the tree. At the same time, there are no GitHub releases, and the feature list carries items that are plainly incomplete. Those two facts together describe the project accurately: an active codebase without a packaged, versioned, supported distribution channel.

For an open source client that reads from a third-party video platform, this is a normal shape for a hobby-led project, but it is a shape with consequences. There is no stable channel to roll back to if a nightly build breaks, so keep an older artifact around rather than assuming the newest download is safe to keep.

Where the local client approach differs from browser-based YouTube front-ends

The two broad ways to use a non-official YouTube front-end are a web interface backed by a separate API server, and a native app that runs on your device. Hyperion takes the second route, and the difference is visible in the repository rather than in the feature list.

A browser front-end of the first kind needs an instance of an API service reachable over the network, usually deployed by the user or by a community. Hyperion instead ships api/ and ktor-brotli/ inside the same Gradle project, and the desktop/ directory suggests a second target sharing that code. The user installs one application on one device, and the request layer travels with it.

That choice buys things the web route cannot offer, most obviously the picture in picture support and a native Compose interface that follows Android conventions. It also brings Android version constraints, since the minimum is API level 21, and it means your device does the fetching and the decoding.

The cost sits in distribution rather than in architecture. There is no Play Store entry to update, no automatic update mechanism, and no versioned release to pin, only a debug artifact link. Anyone who values reproducible installs over device-local processing will find that trade-off unattractive, and it is the clearest reason to wait for the promised GitHub releases.

Editorial conclusion

Hyperion fits Android users who want an ad-free YouTube client with downloads, SponsorBlock and picture in picture and who are willing to sideload a nightly build. It does not fit anyone expecting a stable, release-backed install, and the planned Google account login and custom themes are not in the shipped feature list, so subscribing to YouTube features you cannot use yet is not the point. Before installing, check the download link in the project README on the main branch, confirm your device runs Android 5.0 API level 21 or newer, and read the project status note, which states that development takes longer than usual and that GitHub releases will only be added once Hyperion is in a more stable state.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. zt64/Hyperion on GitHub