Pear Desktop: an Electron wrapper, an NSIS archive for offline installs, and a rename still in the build

It is an unofficial volunteer project, and the disclaimer says so first

The first substantive block in the README is a three-part disclaimer, and its order is deliberate. There is no affiliation: the project and its contributors are not affiliated with, authorized by, endorsed by, or in any way officially connected with Google LLC, YouTube, or any of their subsidiaries. It describes itself as independent, non-profit, and unofficial, developed by a team of volunteers with the goal of providing a desktop experience.

Then trademarks. The names Google and YouTube Music, and related names, marks, emblems and images, are registered trademarks of their respective owners, and any use is for identification and reference only and does not imply association. There is no intention of infringing.

Then limitation of liability. The application is provided as is and you use it at your own risk, and in no event are the developers or contributors liable for any claim, damages or other liability including legal consequences. The responsibility for any and all outcomes rests entirely with the user.

So there is no company behind this. That is a fact about the deployment as much as the code, and it is the first thing to weigh if you are putting it on a work machine.

Five package managers, and SmartScreen will call it an unknown publisher

Installation is covered platform by platform, and every platform has a package manager rather than an installer you download from a page. On Arch Linux there is a package in the AUR. On Solus it is one command:

sudo eopkg install pear-desktop

On macOS it goes through Homebrew, from a cask definition in a separate repository:

brew install pear-devs/pear/pear-desktop

On Windows there are two, Scoop from the extras bucket and Winget, which is Windows 11's official command line package manager:

scoop bucket add extras
scoop install extras/pear-desktop

winget install pear-devs.pear-desktop

The note attached to the Windows section is the honest part. Microsoft Defender SmartScreen might block the installation because it comes from an unknown publisher, and the same is true for a manual download of the executable from this repository, which is the same file. That warning is the expected behaviour for this project on Windows rather than a sign that your download went wrong.

macOS reports the app as damaged, and the fix is one xattr command

There is a specific failure mode on macOS and the README gives the exact remedy. If you install the app manually and get an error saying it is damaged and cannot be opened when you launch it, you run the following in the Terminal:

/usr/bin/xattr -cr /Applications/Pear\ Desktop.app

That is the extended attribute quarantine being cleared, which is what Gatekeeper applies to an application that did not come from the App Store or from a notarised installer. The command strips those attributes recursively from the application bundle.

It is worth being clear about what this command is and is not. It removes a flag the operating system set; it does not verify anything about the application's contents. So if you are about to run it, the check that matters is where the file came from, not the command. A Homebrew cask, which is the route the README recommends first, sidesteps the manual case entirely, and the package managers are the reason this project can say the downloads are traceable.

Offline Windows installs need the NSIS archive in the same folder

There is a documented path for installing with no network connection, and it depends on a pairing that is easy to get wrong. You download the NSIS archive for your device architecture from the release page, where three are named: x64 for 64-bit Windows, ia32 for 32-bit Windows, and arm64 for ARM64 Windows. You also download the installer from the release page, which is a file ending in -Setup.exe. Then you place both in the same directory and run the installer.

The same-directory requirement is the whole mechanism. The installer looks for the archive next to itself rather than fetching it, which is what makes the offline case work at all.

The consequence is that architecture is not a detail here. Downloading the x64 archive on an ARM64 machine and putting it beside the installer produces an installation that either fails or produces a binary for the wrong processor, and the file name is the only clue about which you have. Check the architecture before you download, not after.

Plugins get the BrowserWindow, and the stylesheet import is the entry point

The plugin API is where this project stops being a skin. The stated capabilities are that a plugin can manipulate the app, because the BrowserWindow from Electron is passed to the plugin handler, and can change the front end by manipulating the HTML and CSS.

You create a plugin by making a folder under src/plugins with your own name, containing an index file. The shape is a default export built by a createPlugin call, taking a name, a flag for whether the application should show a restart dialog, a config object holding your own settings, a list of stylesheets, and a menu function. The stylesheet is imported as inline from a CSS file in the same folder, so a plugin that only changes appearance is a CSS file and a small wrapper.

The config methods handed to the menu are all wrapped promises, which is the detail to know if you write one: the menu is async and every access to your settings returns a promise rather than a value.

The manifest still names the old product in escaped unicode

The package manifest is the most revealing file in the repository, and not for the reason you would expect. Its name, its desktop identifier and its product name are all written as unicode escape sequences rather than plain text, and when decoded they spell the previous name of the application rather than the current one. The description, too, and the version, which is 3.12.0 and matches the most recent release tag from 2026-06-28.

Meanwhile the repository field, the author url and the home page all point at the current organisation and repository, the README describes Pear throughout, and the installed application is Pear Desktop. So the identity in the manifest is stale while everything around it has moved.

That is not a cosmetic detail. On macOS the product name in the manifest is what the application bundle and the menu bar item are called, and on Windows the desktop identifier is what an installer registers. A fork or a repackage that trusts the manifest will produce something named after the old product, and any user-visible string taken from it will be wrong.

The build is Electron Vite with a Playwright suite and an electron-builder config

The scripts in the manifest describe a conventional Electron application built with electron-vite. The main entry point is a built file under dist, the module type is ES modules, and the dev script runs electron-vite in watch mode with development environment variables and source maps enabled. There are separate dev entries for the renderer and for the whole application, and a start script that previews a production build.

Testing runs through Playwright, with a debug variant that enables the Playwright debug protocol variables, and a test TypeScript config sits beside the main one at the root. Distribution is handled by electron-builder through a separate configuration file, and the dist scripts build for Windows, macOS and Linux together or for Linux alone, including a Debian package target for ARM64, with publishing set to never so a local build does not upload anything.

The rest of the tree is ordinary and tells you where things live: a plugins area under src, a patches directory, workspace and tool directories, a web directory, a devcontainer, an editor formatter and linter configuration, and a changelog file.

Editorial conclusion

Use Pear Desktop if you want a YouTube Music client that looks native on a desktop and you are comfortable with an unofficial Electron application that no company stands behind. Do not use it if you need a supported product, a clear answer when something breaks, or a guarantee that the service it talks to will keep working. Before you install: read the no-affiliation and liability sections, which place the risk on you; expect an unknown-publisher warning from SmartScreen on Windows and a damaged-app error on macOS that the README has a specific command for; take it from a package manager rather than a random download, since the maintainers warn about those; and if you go offline on Windows, download both the architecture-matched NSIS archive and the installer and put them in the same directory, because that pairing is the documented offline path.

Frequently asked questions

Official sources

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