WebTorrent Desktop streams over AirPlay, Chromecast, and DLNA, and its tests are pinned to two displays

Playback leaves the app through AirPlay, Chromecast, DLNA, or a local player

The app does not only play video on the machine it runs on. package.json carries `airplayer`, taken from a GitHub fork branch named `fix-security` rather than from a registry version, plus `chromecasts` and `dlnacasts`, which cover the two casting protocols most living rooms speak. `vlc-command` is how the project shells out to a local player, `srt-to-vtt` converts subtitles on the fly, and `winreg` is present for Windows registry work. `parse-torrent`, `create-torrent`, and `bitfield` handle the torrent side, and `music-metadata`, `languagedetect` and `iso-639-1` are also in the dependency list. That dependency list is the real feature map of the app: any output path not covered by a cast target or a local player command is not something the project has wired up.

The Mac build can only be produced on macOS

Linux and Windows binaries can be packaged from any platform, and the Mac binary cannot. The stated rule is that the Mac app can only be packaged from macOS, which makes a Mac host a hard requirement for producing a dmg, for signing it, and for the macOS auto-update archive. The consequence lands on continuous integration: a Linux or Windows runner cannot produce a Mac release even though the same command works for the other two targets, so a release pipeline has to hold at least one Mac machine in reserve or the Mac artifacts go missing. Signing compounds it, since the `--sign` option is listed for Mac and Windows and the Windows half of that only works from Windows. There is no cross-compilation path in the docs, and no workaround is offered.

Packaging takes a platform and a package type on the same command

One script builds binaries for Mac, Linux, and Windows, and the same script narrows to a single platform when you pass one:

$ npm run package -- [platform] [options]

`[platform]` is `darwin`, `linux`, `win32`, or `all`, which is the default. The package type is a separate option, `--package=[type]`, and the accepted values are `deb` for a Debian package, `rpm` for RedHat, `zip` for a Linux zip file, `dmg` for a Mac disk image, `exe` for a Windows installer, `portable` for a Windows portable app, or `all`. Passing `--sign` signs the application on Mac and Windows. If you want a Linux portable build, `zip` is the value to reach for, and if you want something that runs without installing, `portable` is the Windows answer.

`--package` cannot suppress the auto-update files

Even with the `--package` option set to a single output type, the auto-update files are always produced: `.nupkg` on Windows and `-darwin.zip` on Mac. That is a deliberate exception to the flag's meaning, and it has a practical cost for anyone trying to produce a clean artifact set. A build that asks for one `deb` still emits the Windows and Mac update payloads, so the output directory contains files the release was not supposed to contain. For a packager uploading to a channel, that means separating artifacts by hand after the fact rather than trusting the flag to keep the directory clean. The docs state the behavior plainly but do not offer a way to turn it off, and they do not say whether the update files are signed when `--sign` is passed. Two platforms are called out and Linux is not, which leaves the Linux update channel undescribed. Contributors looking for the release procedure will find RELEASE_PROCESS.md at the top of the tree, alongside CHANGELOG.md and AUTHORS.md, rather than anything in the README.

Screenshot diffing pins the tests to a Retina MacBook and a 1366x768 screen

The integration tests use Spectron and Tape. They click through the app, take screenshots, and compare each one to a reference image, and the reasoning is given rather than assumed: diffing whole HTML would not catch a bug where hitting ESC from a video fails to restore window size. That choice has a hardware price. On macOS you need a Retina screen at the same resolution as a 2018 MacBook Pro 13 inch, and on Windows you need Windows 10 with a 1366x768 screen. The documented recovery for a mismatch is to delete the offending screenshots and rerun, which recreates them with the new look, and that is also what a small legitimate UI change costs you. Run on an unusual display, the same procedure silently rewrites the reference set, so a green run on the wrong screen proves nothing.

The recommended installer is a 2020 build and the source tree is labeled unstable

Three releases are visible and the newest is v0.24.0, published on 2020-08-29, with v0.23.0 and v0.22.0 both cut on 2020-07-16. package.json still reads `"version": "0.24.0"`, so the manifest has not been bumped past that release either. Against that, the last push to the default branch is dated 2026-10-30, so the tree is being worked on years after the last tag. For an end user this means the newest tagged release is from 2020 and the README recommends downloading from the official website, and the alternative the README offers is to clone the repository for what it calls the unstable development version. The cask is the only command line install it names:

$ brew install --cask webtorrent

Running from a checkout takes three commands and lands you on `npm start`:

$ git clone https://github.com/webtorrent/webtorrent-desktop.git
$ cd webtorrent-desktop
$ npm install

Usage stats measure the play button, not what you watch

The app collects some basic usage stats, and the README is specific about which ones: how well the play button works, whether it succeeds, whether it times out, and whether it shows a missing codec error. Those are interface metrics, and the app is explicit that it never sends any personally identifying information and does not track which torrents you add. That is a narrow collection, but it is still collection, and the README documents no opt-out flag and no setting to disable it, so a user who requires zero telemetry has no documented way to get there from the app itself.

Editorial conclusion

Install WebTorrent Desktop from the official site if you want a single app that plays a magnet link to a local player or a cast device, and read the privacy section before you do, since basic usage stats are collected. Contributors should budget for the display requirements of the screenshot tests and remember that only a macOS host can produce the Mac build, and that installing from source is explicitly the unstable path.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. webtorrent/webtorrent-desktop on GitHub