Seal: a yt-dlp front end for Android, and what its release history tells you

The gap Seal fills: yt-dlp without a terminal

yt-dlp is a Python program. On a desktop that is fine. On Android it is not, because there is no practical way to run a Python CLI, keep it updated, and hand it a URL from a browser share sheet. Seal is the missing layer: a Kotlin app that bundles yt-dlp and exposes it through a Material Design 3 interface. The README describes it plainly as a "Video/Audio Downloader for Android" based on yt-dlp, formerly youtube-dl.

The audience is narrow and specific. It is for people who already understand what yt-dlp does and want that capability on a phone without root, without Termux, and without a desktop in the loop. It is not for someone who wants a general-purpose media player, and it is not a browser extension. If you have never used yt-dlp, the feature list will read as a set of options you have no reason to want: subtitle embedding, metadata and thumbnail tagging, playlist downloads, custom command templates. Those are yt-dlp features wearing an Android UI, and that framing is the honest way to read the project.

The repository's topic list confirms the positioning rather than the marketing copy. It carries android, f-droid, jetpack-compose, kotlin, material-design, youtube-dl, youtube-downloader and yt-dlp. Two of those are the engine, one is the distribution channel, and the rest describe the shell. There is no topic suggesting Seal does anything yt-dlp does not. That is worth knowing before you pick it, because it means your expectations should be set by yt-dlp's extractor list, not by Seal's screenshots.

How Seal actually runs yt-dlp on a phone

The architecture is a wrapper, not a reimplementation. The README lists three external components it embeds: yt-dlp for extraction and downloading, aria2c as an optional external downloader, and mutagen for writing metadata and thumbnails into extracted audio files. That is the whole data flow. A URL goes in, yt-dlp resolves it against its extractor set, and the resulting media is written to storage with aria2c optionally handling the transfer and mutagen handling the tagging.

The consequence of that design is that Seal's real capability ceiling is yt-dlp's. The README points at yt-dlp's own supportedsites.md for the list of supported platforms rather than maintaining one, which is the correct choice and also means Seal cannot download from anything yt-dlp cannot. When a site changes its player and yt-dlp's extractor breaks, Seal breaks with it until the bundled yt-dlp is refreshed. There is no independent extractor work happening in this repository.

The custom command templates feature is the escape hatch for that. The README describes it as executing "custom yt-dlp commands with templates", and the app also lets you manage those templates alongside in-app downloads. If a default option set does not produce what you want, you are expected to reach for yt-dlp arguments rather than wait for a UI toggle. That is a reasonable design for the target user and a dead end for anyone who does not want to learn yt-dlp flags.

One detail worth separating from the rest: aria2c is optional and described as an external downloader, so it is a transport choice rather than a second extractor. Turning it on changes how bytes move, not what can be found. If a URL fails to resolve, aria2c will not rescue it.

Installing Seal and running a first download

The README does not contain build-from-source instructions, so the practical route is the published package. Seal is distributed on F-Droid under the application ID com.junkfood.seal, and the README's badge links to the F-Droid package page. If you have the F-Droid client, the package name is what you search for:

com.junkfood.seal

The README also links a Stable badge to the latest GitHub release and a Preview badge to the releases page including pre-releases. Those two are different channels, and the release list makes the difference concrete: the newest stable entry is v1.13.1 from 2024-10-16, while v2.0.0-alpha.5 is dated 2024-11-29 and its own release title reads "when could we hit beta i dont know". Treat the alpha channel as the author describes it.

Once installed, the first real use is a share-sheet download. The README's feature list covers the mechanics you are choosing between: download the video, extract audio with metadata and thumbnail embedded, or pull an entire playlist in one click. In the app, you paste or share a URL, pick the mode and format, and start the download. If you want aria2c handling the transfer, that is a toggle in the app rather than a command you type. A custom template, by contrast, is where you would put a yt-dlp argument set, because the README documents template execution as the mechanism for running arbitrary yt-dlp commands:

yt-dlp

That is the program the template is handed to, not a Seal command. Seal's contribution is running it for you and storing the template so you can reuse it. The README does not document the exact template syntax or which flags the app passes through, so check the in-app template editor before assuming any given argument is accepted.

The repository layout backs this up. The app lives under app/, the build logic under buildSrc/, and the Android metadata and store listing assets under fastlane/, which is where the screenshot paths in the README resolve. There is no separate CLI or server directory, which is another way of saying the Android app is the whole product.

The release channel is the real risk, not the code

The last push to the repository was on 2026-08-25, so the project is not abandoned. The releases tell a more awkward story. The stable line stops at v1.13.1 (2024-10-16). The 2.0.0 line has produced alpha.4 (2024-10-08) and alpha.5 (2024-11-29), and the alpha.5 release title itself is a question about when beta arrives. Anyone installing Seal today is choosing between a stable release that predates the 2.0.0 work and an alpha series that the maintainer has not declared ready.

That is not a criticism of the maintainer, who is working in public and labelling the state honestly. It is a statement about what you are adopting. If you install the stable release, you get the older UI and the older bundled components. If you install the alpha, you get the current interface and accept that the release notes call it a preview. The README does not document a rollback path between the two, and it does not document a migration for settings or download history. Back up anything you care about before switching channels.

The second failure mode is the one every wrapper inherits. Seal's downloads depend on yt-dlp's extractors matching the current behaviour of the target site. The app bundles its own copy, so a site-side change can break downloads until a new Seal release ships the updated component. The custom command templates mitigate this for argument-level problems, not for extractor-level ones.

There is a third case worth naming, because it is a category error rather than a bug. Seal is an Android app, and it is built for touch. If your actual workflow is a scheduled job that pulls a channel's uploads every night, a phone app is the wrong shape for it regardless of how well it works. The absence of a documented headless mode in the README is consistent with that.

Seal against YTDLnis, and against just running yt-dlp

The obvious comparison is YTDLnis, the other Android front end for yt-dlp that shows up in the same searches. Both wrap the same engine, so the difference is not in what can be downloaded but in the app around it: interface, how command templates are exposed, and which release channel you are expected to run. Seal's README leans on Material Design 3 and a curated feature list; the two projects will diverge on how much raw yt-dlp surface they hand you versus how much they hide behind toggles. If you already know which yt-dlp flags you need on every download, evaluate both on how their template editors behave, because that is where your workflow will actually live.

The other alternative is not an app at all. Running yt-dlp on a desktop or a home server gives you the full CLI, a package manager that updates it independently of any app release, and no bundled-component lag. The trade is that you lose the share sheet and the phone-side convenience, which is the entire reason Seal exists. If your downloads happen at a desk anyway, Seal is the wrong tool and you should not install it.

A third option sits between them, and it is the one to consider if you like Seal's interface but not its update cadence: keep yt-dlp on a machine you control and use Seal only for the cases where the phone is genuinely the right device. That is not a configuration the README describes, but it follows from where the bundled-component lag actually bites.

Licence and the cost of keeping up

Seal is GPL-3.0. For an end user installing from F-Droid or GitHub releases, that changes nothing about how you use it. It matters if you fork it, rebundle it, or ship it inside another product: GPL-3.0 carries source-disclosure obligations for distributed derivatives, and the bundled components have their own licences that you would need to check separately. This is a description of the licence identifier in the repository, not legal advice.

The upgrade cost is the part people underestimate. Seal is a wrapper around a fast-moving extractor, so staying current is not optional if you want downloads to keep working. You are tracking two cadences at once: Seal's own releases, and whatever yt-dlp version each release bundles. The repository does not document an in-app mechanism for updating the bundled yt-dlp independently of the app, so the practical update path is installing a new Seal build. Budget for that, and pick a channel you are willing to reinstall from.

There is also a translation surface to account for. The README links translated versions of itself in Simplified and Traditional Chinese, Arabic, Portuguese, Ukrainian, Thai, Persian, Italian, Azerbaijani, Russian, Serbian, Japanese, Indonesian, Hindi and Bengali, and the repository carries a translations/ directory. That is a maintenance commitment the maintainer has taken on, and it is one more thing that has to keep pace with interface changes between the 1.13.1 and 2.0.0 lines.

What the changelog and contributing files tell a would-be contributor

The repository carries a CHANGELOG.md, a CONTRIBUTING.md and a CODE_OF_CONDUCT.md at the top level, alongside the Gradle build files and a gradlew wrapper. For someone who wants to build it themselves rather than install a release, that is the whole entry point: settings.gradle.kts, build.gradle.kts, buildSrc/, and the app module. The README does not walk through the build, so the Gradle files are the documentation.

The presence of a changelog matters for the channel question above. If you are deciding between 1.13.1 and the 2.0.0 alphas, the changelog is where the differences are recorded, not the README, which describes the product rather than its versions. Reading it before you install is cheaper than discovering a behaviour change after.

What the repository does not carry is equally informative. There is no separate documentation directory, no architecture notes, and no migration guide. The README is the manual. For a wrapper app whose behaviour is mostly delegated to yt-dlp, that is defensible. It does mean that anything the README omits, such as template syntax or channel switching, has to be learned from the app itself.

Editorial conclusion

Adopt Seal if you want a phone-side yt-dlp front end and you are willing to run either the stable 1.13.1 release or track the 2.0.0 alpha channel knowingly. Do not adopt it if you need a documented rollback path or a stable release cadence, because the repository shows neither. Verify first which of the two channels you are installing from, and confirm that the app's bundled yt-dlp can still resolve the sites you care about, since the downloader is a moving target and the app ships its own copy.

Frequently asked questions

Official sources

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