Litube: an Android YouTube client built on a WebView wrapper

A client that is a browser wearing an app's clothes

The repository description calls Litube an advanced webview wrapper for YouTube, and the README states the same thing more fully: Litube is an Android video client with an embedded browser, native playback and built-in downloads.

That one sentence sets the ceiling and the floor for the project. The embedded browser is the engine, so the app inherits the System WebView's rendering and behaviour rather than implementing its own media pipeline. The native part sits on top: native controls for quality, playback speed, subtitles and audio tracks, and native playback itself for local files and for downloaded media.

The target platform is narrow and clearly stated. Litube requires Android 6.0, API 23, or later, and an up-to-date Android System WebView. Picture-in-picture is available on Android 8.0 or later when the device supports it.

The WebView requirement is the one to think about carefully. On Android, the System WebView is a separately updated component, and a client built on it inherits whatever that component does, including its own update cadence and its own behaviour changes. That is a real coupling: a WebView update can change how the app behaves without the app itself changing, and on a device with a stale or vendor-modified WebView, results vary.

The project is GPL-3.0 licensed, written in Kotlin, and the tree is a conventional Gradle Android project with `build.gradle.kts`, `settings.gradle.kts`, a `gradlew` wrapper, an `app/` module and a `fastlane/` directory holding the store metadata and screenshots.

It is worth naming plainly what this software is not. It is a third-party front end for a video service, not a media hosting or a catalogue project, and its features exist to give the user control the first-party app does not offer.

The feature list, and the one that depends on site internals

The README's feature list is where the design decisions are visible, and one of them stands out.

Ad-free playback and configurable sponsor segment skipping is listed first. A client that recognises and skips sponsor segments is doing something the first-party app does not. This is also the feature most exposed to change, because it depends on how the service currently presents those segments to the player, and a client that pattern-matches on that presentation is working against a moving target. The same is true of the downloads feature, which the README lists as video, audio and playlist downloads with quality and language selection.

The rest of the list is ordinary, well-executed client work. Native controls cover quality, playback speed, subtitles and audio tracks. Playback modes include audio-only, background playback, picture-in-picture and a mini-player. There are local queues, playlist playback and autoplay, plus voice search, live streams and live chat.

Two entries are worth pulling out because they are the kind of feature that separates a personal app from a shipped one. Casting works through an open-source sender, as the README states. Settings backup and restore, and diagnostic reports that can be saved or shared, are the two features that a support channel actually depends on, and they are the reason the contributing guidance asks for a diagnostic archive.

That guidance is worth reading as a signal about the state of the project. It asks reporters to include the app version, device model, Android version and steps to reproduce, and to attach a diagnostic archive when available. That is a maintainer who has decided that good bug reports matter, and it is a reasonable expectation of any app with a WebView core, where the same symptom can come from the app, the WebView, the device or the service.

The v4 rewrite: replacing the WebView with native components

The roadmap section contains a single item, and it is the most important line in the README:

Replace the WebView-based architecture with native Android components, planned for v4.

An unchecked box in a roadmap usually means something aspirational, and the project deserves the benefit of the doubt given that it has shipped three releases in the first three weeks of October 2026, v3.0.1 on 2026-10-08, v3.0.2 on 2026-10-10 and v3.0.3 on 2026-10-16. But the item is also a candid statement of the current architecture's limits.

The reason a WebView wrapper exists at all is that a first-party web player handles authentication, playback and session state in ways that a native client has to imitate. A wrapper gets those behaviours for free because it is running the real site. The cost is that the app is then coupled to the site's own front end, and anything the site changes can break the wrapper.

A native implementation removes that coupling but reintroduces the hard part: implementing playback, the API calls and the sign-in flow natively, which is why it is a v4 project rather than a v3.1 patch. A team considering Litube today is therefore choosing between a feature-complete client that depends on the WebView, and a promise of a native one that does not exist yet.

That also means the version number tells you which kind of client you have. The 3.x line is the WebView architecture, and the README's current version line says 3.0.3, so the native rewrite is a future state of the project rather than something you can install today.

Installing from the releases page, and what to check first

There is no build-from-source path documented in the README, so the install story is the releases page.

The README says installation packages and release notes are on the releases page, and gives the current version as 3.0.3, which matches the release tag v3.0.3 dated 2026-10-16. The last push to the default branch was on 2026-10-18, so the branch is slightly ahead of the newest release.

Before installing on a real device, three checks are worth making.

First, the System WebView. The requirement of an up-to-date Android System WebView is not a formality for a WebView-based client, and if the device's WebView is old or replaced by the manufacturer's own build, behaviour can differ markedly between phones. Updating the WebView is the first thing to try when the app misbehaves.

Second, the platform floors. Android 6.0, API 23, is the minimum, and picture-in-picture needs Android 8.0 plus device support, which the README states plainly rather than assuming.

Third, the build source. The repository contains a `fastlane/` directory with the store metadata and the English phone screenshots referenced in the README, along with a full Gradle project including the wrapper, `gradle.properties` and a `build.gradle.kts`. That is enough to build the app from source if you want to, and the README's contributing section says contributions and pull requests are welcome, which implies a source build is expected to be possible even though the steps are not in the README.

Whether to install the release APK or build from source is a decision about trust and about time. The release package is the faster path; building it lets you read the code and change it, which is the point of a GPL-3.0 project.

Where Litube is the wrong tool

The first wrong-tool case is a device without a usable System WebView, or a user who does not want the app coupled to the site's front end. Given that the v4 rewrite exists precisely to remove that coupling, an adopter who cares about longevity is waiting for something that does not exist yet.

The second is iOS or desktop. The README is specific about Android, with Android version and API level requirements stated for every feature, and the tree is a Gradle Android project with fastlane metadata for the Play Store. There is no iOS or desktop client here.

The third is a user who wants the ad-free and download features to keep working indefinitely. This is the honest limitation of the whole approach. Sponsor segment skipping and downloading both depend on the service's current behaviour, and both are the kind of feature that breaks when the service changes, or when it decides to route media in a way the client cannot follow. A user who depends on those features is depending on a moving target, and the app's own roadmap acknowledges the architecture problem.

The fourth is reliability-critical use. A client that depends on a browser component and on a remote site is a client whose failure modes are not yours, and for a service that has to be up every day that is a different risk profile from a native app talking to an API.

The alternative worth naming is the first-party application, and the difference in approach is straightforward. The official app is a native client with its own media pipeline, updated together with the service, and it will keep working when the site's front end changes. What you give up is the control that this project exists to offer: adjustable quality, explicit subtitle and audio track selection, background and picture-in-picture playback, offline downloads, and the absence of advertising. Whether that trade is worth making depends on whether you use the advanced features or just watch videos.

Maintenance, licence and the shape of the release cadence

The recent release history is dense. Version 3.0.1 was tagged on 2026-10-08, v3.0.2 on 2026-10-10 and v3.0.3 on 2026-10-16, and the last push to master was on 2026-10-18. Three patch releases in nine days is the pattern of an application being iterated on quickly, and for a client whose behaviour depends on a remote site, that pace is what you want, because a change on the service side needs a client release to follow it.

The repository is not archived, and the fact that the master branch moved two days after the latest tag suggests work in progress that has not yet been cut as a release.

The licence is GPL-3.0, with a `LICENSE` file at the top level. That is a strong copyleft licence, and it is the right choice for an app of this kind, because it guarantees that anyone who improves the client and distributes the result has to publish their changes. For a user who just installs the release package, GPL-3.0 carries no practical obligation, and for a developer who wants to fork the app, the copyleft is the mechanism that keeps a fork open. This is a description of the terms as published, not legal advice.

The tree also has `.github/` for the workflows, an `app/` module for the application code, and the fastlane metadata that carries the store listing and the screenshots. The last of those is the one to look at first when evaluating the app, since the README's screenshots are the same images and the store listing is where the current feature set is actually described.

Editorial conclusion

Adopt Litube if you are on Android 6.0 or later, you want native quality, subtitle and audio track controls plus picture-in-picture and downloads, and you are comfortable with a client that is a WebView wrapper until the planned v4 rewrite lands. Do not adopt it if you need a client that does not depend on the System WebView, or if you want an architecture that will not need replacing, because the roadmap states the WebView-based architecture is being replaced with native Android components in v4. Before installing, check that your device has an up-to-date Android System WebView, decide whether the download and ad-skipping features are ones you want to rely on given they depend on how the site serves media today, and note that the newest release is v3.0.3 from 2026-10-16 while the last push to master was on 2026-10-18.

Frequently asked questions

Official sources

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