Ghost Downloader 3 ships signed desktop builds, an aria2 RPC and a plugin API you cannot write against yet

No install command anywhere in the docs, only a website and an AUR package

The README gives no pip, npm or curl install line for the app itself. Its only install step is for the `ghd` command line tool, which you add from Settings -> Command Line Tool once the desktop app is running. The paths that do exist are a homepage at gd.xychr.com, a documentation site at gd.xychr.com/en/docs/, issue forms for bugs and feature requests, a Discord invite and a QQ user group numbered 756042420.

The one exception is Linux, where community packages named `ghost-downloader-bin` and `ghost-downloader-git` exist in the Arch Linux AUR, maintained by @zxp19821005. That is a distribution choice, not the project's own.

The README's only other command lines are the contribution sequence, which is a reasonable place to start if you intend to patch rather than install:

git checkout -b feature/AmazingFeature
git commit -m 'Add some AmazingFeature'
git push origin feature/AmazingFeature

Binaries are code signed for free by SignPath.io, with certificates from the SignPath Foundation, and separately by i0ntempest.com.

Four platform rows and one CPU instruction that vanished

The support matrix is four rows with hard floors. Windows needs version 10 or newer on `x86_64` or `arm64`. macOS needs 13.0 or newer on `x86_64` or `arm64`. Linux needs `glibc 2.35+` on `x86_64` or `arm64`. Android needs 9.0 or newer and is listed for `arm64-v8a` only.

Each of those numbers is a way the app fails to start rather than a preference. A glibc 2.35 requirement excludes older enterprise distributions outright, and the ARM row on Android is narrower than the desktop rows, so a 32-bit Android device has no listed target. macOS 13.0 is the same story in reverse: anything older than a 2022 release is out.

There is also a hardware floor that is easy to miss. A warning states that Qt 6.6 and later no longer supports CPUs without the `AVX` instruction set. The interface is built on PySide6, pinned at `pyside6~=6.10.3`, so a pre-AVX machine gets no build at all. Translation work is centralized on Crowdin under the project name `ghost-downloader`, and the repository keeps a Simplified Chinese README alongside the English one.

Each protocol is somebody else's engine underneath

The protocol list reads like one program, but the dependency list shows a stack of borrowed engines. Magnet and BT go through `libtorrent`, declared at `2.1.1` or newer. FTP uses `aioftp[socks]>=0.27.2`, which is where SOCKS proxy support comes from. M3U8 and MPEG-DASH handling uses `m3u8>=6.0.0` and `mpegdash>=0.4.1` as parsers.

On top of that sit site specific paths: YouTube and Bilibili with clip selection, any quality, subtitles, playlists and multi part episodes, and GitHub and HuggingFace with mirror acceleration. `qrcode[png]>=8.2` and `desktop-notifier>=6.2.0` cover sharing and completion alerts.

What that composition means for you is upgrade coupling. A parser bump inside m3u8 or a libtorrent release can change download behavior without a change in Ghost Downloader itself, and a stalled HLS download is not necessarily a bug in this app. The core claim of smart chunking without file merging and automatic bandwidth detection sits above these engines, not inside them.

The aria2 compatible RPC is the seam meant for other tools

The documented integration point is an `aria2`-compatible RPC API for third party tools. That, together with the `ghd` command line tool, is how the app is meant to be driven by something other than its own window: an existing front end that already speaks aria2 can talk to Ghost Downloader instead.

Alongside it sit three promises about running tasks: you can change the URL, the headers or the proxy mid download, and progress is never lost. Editing a task in place rather than restarting it is the practical difference, since a restarted transfer gives up bytes already fetched. The `websockets>=14` dependency sits in the same stack as the RPC claim, alongside `wreq>=0.12.0`, which is the request layer.

The roadmap still lists binding multiple Sessions to one task as unfinished work.

Feature Packs run, but the plugin API is still unchecked

The plugin story is half built, and the gap is stated rather than implied. The Feature Packs system is described as operational, with the API described as stabilizing, and the roadmap's first open item is making the plugin API public. The second open item is enhanced task editing, such as binding multiple Sessions to one task.

In the repository, the `features/` directory sits alongside `app/`, `browser_extension/`, `docs/`, `dist/`, `scripts/`, `tests/` and `tools/`, with `Ghost-Downloader-3.py` at the root as the entry point, plus `AGENTS.md` and `CLAUDE.md` for agent oriented work, and `GLOSSARY.md`. The pytest configuration puts both `.` and `features` on the python path, so the feature modules are importable as first class code.

The practical consequence is that you can read how packs are wired, and you can see them load, but you cannot build a pack against a contract that will not change. The README describes the API only as stabilizing. For a plugin author, that makes now a reasonable time to read the source and a poor time to ship something users will upgrade against.

The extension carries your login state, so it needs the desktop app

The browser extension is the part that makes the app feel automatic. A download button follows the video on the page, the popup lists every medium the page exposes, and clicking there or simply starting a download normally hands the job to the desktop app. Authentication state carries over, so a page you are signed into stays signed into.

That last sentence sets the boundary. The extension does not download anything on its own; it moves URLs and credentials to the native application. Since the app ships as native binaries on Windows, macOS, Linux and Android, the extension is paired with whichever desktop build you installed, and the handoff depends on that app being present and running.

The platform table lists Windows, macOS, Linux and Android. There is no iOS row, no required version and no architecture for it, so the frequent search for an iOS build has nothing in the documentation to match.

Tests run with warnings as errors and a network marker

The test setup is unusually strict for a desktop app. Pytest is configured with `testpaths = ["tests"]`, `asyncio_mode = "auto"` and `qt_api = "pyside6"`, and `addopts` forces `--strict-markers --strict-config`. The `filterwarnings` table turns warnings into errors, with only two narrow exceptions: `pytest.PytestUnraisableExceptionWarning` and a coroutine never awaited `RuntimeWarning`.

One marker exists, `network: requires internet access`, so tests that need a real connection are declared rather than silently skipped. Development dependencies include `aiohttp`, `brotli`, `zstandard` and `types-libtorrent`, which suggests coverage of compressed and torrent responses rather than only happy path files.

The project metadata declares version `4.4.6`, matching the newest release tag `v4.4.6`; the recent tags are `v4.4.4`, `v4.4.5` and `v4.4.6`, published between 2026-10-20 and 2026-10-28. `uv.lock` and `versions.json` sit alongside it at the top level, and the last push to the repository was on 2026-10-29.

Editorial conclusion

Ghost Downloader 3 is a reasonable pick for someone who wants one desktop app instead of five protocol specific tools, and a poor fit for anyone who needs an iOS build or a stable plugin API. Before committing, check the platform floor against your own machines, since the Linux build asks for glibc 2.35 or newer and Qt 6.6 dropped CPUs without AVX. Also check where binaries come from: code signing is handled by SignPath.io and i0ntempest.com, and the GPL v3.0 license means anything you link against carries obligations.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes