BetterDiscord Installer: a Wails desktop app that patches your Discord install

A Go backend with a Svelte frontend, shipped as a native app

The installer is a desktop application rather than a shell script, and the stack is stated plainly in the README: it is built with Wails, which pairs a Go backend with a Svelte frontend, and it ships as a native desktop application. The module in go.mod is named installer and requires Go 1.26.0, with the Wails runtime at github.com/wailsapp/wails/v2 v2.11.0 as the main dependency.

The rest of the dependency list is small and tells you what the program actually does. github.com/shirou/gopsutil/v3 v3.24.2 is a cross-platform library for system and process information, so the app queries the machine it is running on. github.com/pkg/browser opens URLs in the default browser, which is how a desktop app hands you to a web page. github.com/tc-hib/winres v0.3.1 is a Windows resource compiler, used to stamp the executable with its icon and version metadata at build time. There is no database, no network client library and no update framework in the list, which is consistent with a utility whose whole job is a local file operation.

The repository layout matches that picture. At the top level sit main.go, app.go and a platform-specific backend_linux.go, with directories named betterdiscord/, discord/, api/, frontend/, types/, utils/, scripts/ and wsl/. A separate betterdiscord package and a separate discord package suggests the two sides of the operation are modelled apart, and wails.json holds the Wails project configuration.

Windows leans on WebView2, Linux needs WebKitGTK 4.1

The compatibility matrix is where this kind of application usually surprises people, because a Wails app is not self-contained on every platform. On Windows the minimum is Windows 10 on x64, and the note says it uses the system WebView2 runtime, which means the Edge webview present on a current Windows install is what renders the interface. On macOS the minimum is macOS 12, Monterey, and the build is a universal binary covering both Intel and Apple Silicon.

Linux is the demanding case. The requirement is any x64 distribution with WebKitGTK 4.1, and the README gives concrete examples: Ubuntu 22.04+, Debian 12+ and Fedora 37+. That is a real installation step on a lot of systems, since the WebKitGTK version in older distributions is below what the toolkit needs, and the failure mode is a blank window or a launch error rather than a clear message in most cases.

The platform split in the source reflects the same reality. There is a dedicated backend_linux.go alongside the shared app.go, and the release matrix in .goreleaser.yaml covers Windows, macOS and Linux builds, with the Linux side shipping both an AppImage archive and a plain zip for people who do not want to grant AppImage execution rights on their system.

For an organisation that builds its own images, this is the line to check: the Linux package is not a single static binary, it is a webview application that expects a particular GTK webkit version to be present.

Snap Discord is unsupported because the mount is read-only

The Linux section of the compatibility notes is the most useful part of the README for a reader who has not yet installed anything, because Discord on Linux comes in three flavours and the installer treats them differently.

A native Discord install is fully supported. A Flatpak Discord install is supported for per-user installs, with an explicit warning that system-wide or global installs need elevated write access and are not supported yet. A Snap Discord install is not supported at all, and the reason given is mechanical rather than cautious: snap mounts Discord's files read-only, so the installer cannot modify the app.

That reason generalises. Any installation model where the Discord files are immutable by design will defeat an installer that works by modifying the application directory, and that includes corporate image policies and immutable distributions. If your Discord came from the snap store, the answer is that this tool cannot do the job, and you would have to use a different Discord package or a different approach entirely.

The Flatpak caveat follows the same logic. A per-user Flatpak is writable by the user, so the modification succeeds. A system-wide Flatpak belongs to root, so writing to it needs privileges the installer does not assume.

Four download routes, and a package manager on two of them

Installation is deliberately frictionless. The releases tab publishes four artefacts: BetterDiscord-Installer-Windows.exe, BetterDiscord-Installer-Mac.zip, BetterDiscord-Installer-Linux.AppImage.zip and BetterDiscord-Installer-Linux.zip. The two Linux options exist for different preferences, with the AppImage for users who are happy to make the file executable and the zip for users who are not.

winget install BetterDiscord.Installer

brew install --cask betterdiscord/tap/betterdiscord-installer

The first block installs on Windows through the winget package manager, and the second installs the macOS cask through Homebrew. The README presents these as alternatives to downloading the archives by hand, and the direct download links are listed for the platforms where no package manager entry is given.

A first run should be a small, reversible thing. The program automates installation, removal and maintenance of BetterDiscord, so the same executable that installs it is the one that removes it, which means you can uninstall a change you do not want without a second tool. The repository includes a Taskfile.yml and a scripts/ directory for the development workflow, and a .github/ directory for the workflows, but the end user does not need any of that.

What you should see on launch is a small desktop window with the options for the actions the app supports, and a browser tab opening if you follow a link from it, which is what the pkg/browser dependency is there for.

SmartScreen warns because the installer is not code-signed

The first FAQ entry in the README addresses a problem every new Windows user hits. When you run the installer, Windows may show the message that Windows protected your PC. The cause is stated without hedging: the installer is currently not code-signed, so SmartScreen warns.

This is the main friction point of the whole project and it is worth being blunt about it. A code signature is what tells Windows that a binary came from a known publisher. Without one, SmartScreen treats the file as unknown, and the user has to click through a warning that looks identical to the ones that appear for genuinely malicious software. On a managed workstation, that click-through may be blocked by policy entirely, which turns a two-minute install into a support ticket.

The go.mod dependency list explains why signing is not there. github.com/tc-hib/winres is present, which is the tool for embedding an icon and version information into the Windows executable, and that work is the same category of task as signing but not the same task. Signing requires a code signing certificate from a certificate authority, and the repository shows no signtool invocation in the build configuration, only resource compilation.

So the practical advice for a team evaluating this is narrow but specific: check the SmartScreen behaviour on your own managed machines before you recommend the installer to users, and consider the macOS and Linux packages first if your fleet is not Windows-centric, since the compatibility matrix lists no equivalent gatekeeper warning for them.

MIT licensed, a three-year gap before the 2.0 rewrite

The licence is MIT, which is permissive. You can use, modify and redistribute the code, including commercially, provided the copyright notice and the licence text are kept. The repository has a LICENSE file at the root and the README links to it. That is a licensing fact rather than legal advice, and it matters here because the installer is distributed as a binary to end users, so a fork can be signed, rebranded and shipped without a licence negotiation.

The release history is where the project looks unusual. v2.0.0 was published on 2026-08-27, and the release before it was v1.3.0 on 2023-05-15, with v1.2.1 in March 2023. That is a gap of more than three years between the two most recent versions, and the 2.0.0 number matches the rewrite: the v2 release is the Wails and Svelte application described here, while the 1.x line was the previous implementation.

Between them, the current signals are good. The repository is not archived, the default branch is development rather than master or main, and the last push was on 2026-08-30, three days after the v2.0.0 tag. Development as the default branch is the normal pattern for a project in its first weeks after a rewrite, and it means the tagged release is not necessarily the newest code.

One oddity in the tree is the pair of AGENTS.md and CLAUDE.md at the root, alongside CONTRIBUTING.md. Those are instructions for coding agents rather than for users, and their presence tells you the project expects automated contribution tooling, which is worth a look before you open a pull request.

The alternative is doing the file work yourself

There is a second way to install BetterDiscord, and the difference is where the effort goes. Doing it by hand means locating the Discord application directory on your platform, modifying the files there yourself, and repeating that process after every Discord update, since an update replaces the application directory and removes the changes.

The installer takes that work and puts it behind a native interface. It knows where the Discord files live for a native install, a per-user Flatpak and the other layouts it supports, it performs the modification, and it offers removal and maintenance as first-class operations rather than something you reverse by hand. It also handles the version-specific details of the Discord client layout across platforms, which is where a manual procedure usually breaks.

The cost of the automated route is the trust and the binary. You run a program that rewrites the files of an installed application, it is not code-signed, and it is a native binary rather than a script you can read before running. For a personal machine that trade is usually fine. For a fleet, the equivalent to the manual route is to script the same steps yourself with a script you control, which gives you the repeatability without handing the operation to an opaque executable.

The other side of the trade is updates. A script you maintain yourself can be adjusted for a new Discord layout in minutes, whereas the installer has to ship a new build, which is a slower loop for anyone who hit a version-specific problem on the day it appears.

Editorial conclusion

BetterDiscord Installer fits a Windows, macOS or native Linux user who wants BetterDiscord installed and later removed or updated without editing the Discord application directory by hand. It does not fit a Snap Discord user, because the snap mount is read-only, and Flatpak users are limited to per-user installs. Before running it, check which of the three Linux packaging routes your Discord came from, and on Windows expect the SmartScreen warning, because the installer is not code-signed and the README says so explicitly.

Frequently asked questions

Official sources

1. BetterDiscord/Installer on GitHub
2. License: MIT
3. Project website
4. README
5. Releases