AriaNg Native: wrapping the AriaNg web frontend in an Electron shell

A frontend that needs an aria2 daemon behind it

The repository description is blunt about positioning: a better aria2 desktop frontend than AriaNg, with all features of AriaNg and more for desktop usage. That makes the relationship worth being clear about, because AriaNg Native is not a download manager. It is a window around the AriaNg interface, and AriaNg in turn is a frontend for aria2, the command line download utility. The README states it directly, that AriaNg Native is built by Electron and carries all features of AriaNg, then defers the AriaNg documentation to its own repository.

The practical consequence is that an aria2 instance has to be running somewhere for any of this to display anything. AriaNg Native talks to aria2 over the JSON-RPC interface that aria2 exposes, and the app itself does not download files. Readers who come from a browser tab expect a self-contained application and get a client for a separate daemon instead.

What the wrapper does change is the ergonomics. The README's list of extra features is specific rather than aspirational: create a task by dragging a file or URL onto the window, view torrent file information and pick which files to download before the task starts, and play a sound when a download finishes. Those are the interactions a browser tab cannot offer, and they are the reason the project exists.

The command line accepts a file, not a download

The README's command line section is the most useful thing in the repository, because it turns the GUI into something scriptable. The usage line takes a single positional file argument, and the default command creates a new download task from an existing torrent or metalink file:

Usage: AriaNg Native.exe [file] [options]

Commands:
  AriaNg Native.exe new [file]  Create new download task from exist
                                torrent/metalink file                  [default]

The flag set is small and each flag does something a desktop app genuinely needs. `--development` enables debug mode, `--classic` restores the classic window title bar on Windows, and `--minimal` hides the main window at startup, which is what makes a tray-only launch possible. Note that the argument is a file on disk, not a magnet URI, so magnet handling arrives through the protocol handler described further down rather than through this interface.

The Windows executable is named with a space in it, AriaNg Native.exe, which is worth keeping in mind when writing anything that shells out to it. Paths containing spaces need quoting, and the `new` keyword is optional since it is marked as the default command.

Eight desktop features the browser version cannot do

The README groups the additions into eight numbered items, and each one maps to a desktop capability the web frontend is structurally missing. Three are interface and task behaviour: a more user friendly interface overall, drag-and-drop task creation, and the ability to see torrent file information and choose which files to download before the task is created. That third one is the feature that matters most in practice, because it is the difference between fetching an unwanted 8 GB sample and fetching the one file you wanted.

Three more are operating system integration points: file associations for .torrent and .metalink files, magnet link protocol handling so the browser can hand a task to the app, and a taskbar tray that supports minimizing to tray. Two are local behaviours: local file system operating support and executing a custom command on startup. The last is checking for updates on startup.

That mix tells you the design intent. AriaNg Native is trying to be the app you leave in the tray rather than a page you keep open, which is why magnet protocol handling and file associations matter as much as the UI improvements. The homepage at ariang.mayswind.net sits outside the repository, so the visual side of the work is documented there rather than in the source tree.

Building the installers with electron-builder configs

Building from source needs Node.js and NPM, then three npm scripts per platform. The two publish scripts are long chains that clean, generate a build manifest, copy dependencies in two separate passes and then hand off to electron-builder with a platform-specific config file:

    $ npm install
    
    # For Windows
    $ npm run publish:win
    
    # For macOS
    $ npm run publish:osx

The repository tree shows why the chain is that long. There are three separate electron-builder configuration files, one for macOS and two for Windows at x86 and x64, so a Windows build produces both architectures. Alongside them sit copy-main-modules.js and copy-app-dependencies.js, two nearly identical scripts that handle the main process and the renderer process separately, plus generate-build-json.js which stamps version information. The dist directory receives the output.

Two details in the manifest matter more than they look. The `engines` field requires Node 14 or newer, and `electron` is pinned at ^22.3.7, which places this on the Electron 22 line rather than the current release. There is also a `postinstall` hook running install-app-deps, the standard electron-builder command for rebuilding native modules against the packaged Electron, so a fresh clone needs that to succeed before any build will work.

Translations live in app/langs and flow through pull requests

The translating section is short but unusually specific about the mechanics, which tells you the maintainer handles contributions rather than delegating them. All translation files sit in `/app/langs/`, and the instruction to contributors is simply to modify one and open a pull request. Adding a language from scratch takes three steps: add a language configuration to `/app/scripts/config/languages.js`, copy `/i18n/en.sample.txt` into `/app/langs/` and rename it to the language code, then fill it in.

The i18n directory in the tree holds that sample file, and the two copy scripts at the repository root handle the module copying for the build. The path split is a little unusual, with app code under app/ and the main process under main/, but it follows from Electron's two-process model: the entry point is app/index.html and the main process entry is main/main.js.

A reader planning to add a language should know that the sample file in i18n/ is the template and the finished file belongs in app/langs/. Getting those two backwards produces a translation the build never picks up.

Version numbers to check before you trust the build

There is a discrepancy in the version information that is worth flagging plainly rather than resolving on the author's behalf. The package manifest records version 1.3.15 and a separate ariang-version field also at 1.3.15, while the newest published release on GitHub is 1.3.14, published on 2026-06-20. Those two facts are both in the repository and both are true.

The release notes explain the pattern. Version 1.3.14 updated AriaNg to 1.3.14 and added support for registering as the system's default magnet link downloader, credited to a pull request. Version 1.3.13, from 2026-01-25, updated AriaNg and allowed adding multiple URLs at once by drag-and-drop in the new task page. Version 1.3.12, from 2025-12-14, was a straight AriaNg update.

Each release moves the embedded AriaNg version in lockstep with the app version, so the two numbers tracking each other is the intended behaviour rather than a mistake. What it means practically is that the manifest is one step ahead of the last release, which is the normal state of a repository between releases. If you are pinning a dependency or writing a support article, cite the release tag rather than the manifest. The repository is not archived and the last push was on 2026-09-12.

Editorial conclusion

AriaNg Native is a packaging project rather than a redesign, and the repository is honest about that. AriaNg stays the interface, Electron supplies the window, and the value sits in the eight desktop features listed in the README: drag and drop task creation, torrent file selection before a task starts, a sound on completion, command line arguments, .torrent and .metalink associations, magnet protocol handling, a tray icon and an update check on startup. Build it with npm run publish:win or npm run publish:osx, and read the command line section before scripting task creation, since the file argument is the whole interface. One number needs checking before you rely on it: the manifest says 1.3.15 while the newest tagged release is 1.3.14.

Frequently asked questions

Official sources

1. License: MIT
2. mayswind/AriaNg-Native on GitHub
3. Project website
4. README
5. Releases