Wire Desktop: an Electron shell around wire-webapp, with a managed app-lock override

What the Electron layer actually adds

Wire Desktop is described as a cross platform desktop app that wraps the wire-webapp, based on Electron. The webapp repository is separate, and the desktop repository holds the native shell, the build and release machinery, and the platform integrations.

The dependency list in package.json explains what those native pieces are. There is @electron/remote, archiver for building the packaged artifacts, auto-launch for the login item behaviour, electron-dl for downloading the runtime and electron-updater for the self-update path. The Wire side comes from @wireapp packages, with commons, protocol-messaging, certificate-check, react-ui-kit, open-graph and webapp-events, plus @hapi/joi for schema validation and axios for HTTP.

The macOS single sign-on work is the most detailed part of the README. Desktop SSO on macOS uses ASWebAuthenticationSession through an optional objc-js bridge, with authentication running in a supporting default browser and Safari as the fallback. Windows and Linux retain embedded SSO, and the standalone webapp is unchanged. The README notes the macOS flow follows the same backend contract as Wire iOS, where a validated callback returns a session cookie to the initiating account, and states explicitly that callback URLs and cookies must not be logged. It also says this is not a single-use-code PKCE exchange, which is a security-relevant distinction rather than a technicality.

On packaging, the macOS build unpacks and signs the native bridge using the existing app-signing identity, and browser SSO no longer requires the former WebAuthn keychain-group entitlement or additional provisioning-profile credentials. Both Jenkins jobs use the configured node-v23.0.0 tool for the upgraded Electron runtime.

Building from source with Yarn, and running the tests

The prerequisites are Node.js matching the version defined in .node-version, Npm, Git and Yarn, with the README pointing at the official Yarn install instructions and asking you not to use the package recommended by apt-get.

The dependency install on a Debian style system looks like this.

sudo apt install git npm nodejs
npm install --global yarn

Then you clone and install.

git clone https://github.com/wireapp/wire-desktop.git
cd wire-desktop
yarn

Starting the app and running the tests are the two commands you need next.

yarn start
yarn test

The repository layout explains why the toolchain is as large as it is. There is a jest.config.js for the unit tests, a playwright.config.ts and a tsconfig.playwright.json for the end-to-end tests, an e2e-tests/ directory, a webpack.config.cjs and a babel.config.cjs for the build, and separate tsconfig files for the build, the bin directory and the mocha configuration. There is also a .nycrc.json for coverage and a .cspell.json for spell checking.

The build tasks for shipping are named by platform.

yarn build:macos
yarn build:win
yarn build:linux

The electron/ directory holds the main process and preload code, app-config/ holds configuration, resources/ holds static resources, and a jenkins/ directory with the CI job configuration, plus crowdin.yaml, which tells you the UI strings are translated through Crowdin.

The applockOverride flag, and how each OS delivers it

On company-managed devices, an MDM administrator can force app-lock on, overriding the team-level app-lock setting. The README describes the implementation precisely, and the precision is the point.

The desktop app reads a single applockOverride flag at startup, without spawning any shell command, and forwards it to the webapp as window.desktopAppConfig.managedConfig. That last detail is a security property, because a shell command would be a command injection surface on a device that an administrator, and therefore an attacker, can place a value in.

The flag comes from organization-agnostic, Wire-vendor locations, with no customer or company name hardcoded. On Windows it is a registry value at the Policies\Wire key under HKLM with an HKCU fallback, and the value applockOverride equal to 1 counts, as does the device being MDM-enrolled or Azure-AD joined. On macOS it is a boolean in the app's managed preferences domain, an MDM AppConfig profile, with applockOverride true. On Linux it is a JSON file at /etc/wire/managed.json containing an object with applockOverride set to true, and the presence of the file means managed unless it is explicitly false.

The three test recipes are given, one per platform.

echo '{"applockOverride": true}' | sudo tee /etc/wire/managed.json
# relaunch app -> applockOverride === true
sudo rm /etc/wire/managed.json

On Windows the equivalent is a reg add against HKLM\SOFTWARE\Policies\Wire with the value name applockOverride, type REG_DWORD and data 1, undone with reg delete. On macOS it is defaults write against the running build's bundle id, which in production is com.wearezeta.zclient.mac, with dev and internal builds differing. The macOS recipe also has a second form for the real MDM path, writing to the managed preferences domain at /Library/Managed Preferences.

The verification procedure is the same everywhere. Plant the flag, relaunch the app, open DevTools on the webapp's webview, and evaluate window.desktopAppConfig.managedConfig, which should show applockOverride true. With nothing planted it must read false and the app must behave as before.

The four stage release pipeline

Wire Desktop ships through a four stage branch pipeline, and the README spells out the branch, the merge type and the version increment for each stage.

Stage 1 is feature development, on a varying branch, where you commit, and the version is x.y+3, for example 3.20. Stage 2 is nightly test automation on the dev branch, where you commit or squash merge from the feature branch, and the version is x.y+2, for example 3.19. Stage 3 is the internal release on the staging branch, merged without squashing from dev, at x.y+1, for example 3.18. Stage 4 is the production release on main, merged without squashing from staging, at x.y, for example 3.17.

The squash rule changes between stages, which is deliberate. Squash merges are used on the way into dev, where a noisy feature branch does not matter, and normal merges are used for staging and main, where a linear, readable history does.

Two compare views are linked for reviewing what moved between stages, one from dev to staging for the changelog and one from staging to main.

The published releases follow the same numbering. The recent tags are windows/3.44.5377, macos/3.44.5495 and windows/3.43.5376, and the platform prefix in the tag name is the useful detail, since Windows and macOS builds are versioned independently and are not always released on the same day. The last push was on 2026-10-15, and the default branch for this repository is dev, which is stage 2 of the pipeline rather than the production branch.

The licence is GPL-3.0, but the terms around it are not the usual ones

The repository is GPL-3.0, and there is a LICENSE file at the root. But the README adds a layer that most open source projects do not, and it is the most important paragraph in the document for anyone considering building on this code.

The README says that if you compile the open source software made available to develop your own mobile, desktop or web application, and cause that application to connect to Wire servers for any purposes, the result is referred to as an Open Source App. All Open Source Apps are subject to, and may only be used and commercialized in accordance with, the Terms of Use applicable to the Wire Application. Four restrictions then follow.

You agree not to change the way the Open Source App connects and interacts with the servers. You agree not to weaken any of the security features. You agree not to use the servers to store data for purposes other than the intended and original functionality. And you acknowledge that you are solely responsible for any and all updates to your Open Source App.

The carve-out is explicit too. If you compile the software and do not cause the application to connect to Wire servers for any purposes, then it is not deemed an Open Source App and the foregoing terms do not apply.

That last sentence is the practically useful part. The GPL-3.0 grant covers the code, but the right to ship a Wire-compatible client is bounded by the Wire terms, and the boundary is the network connection rather than the code itself. Separately, no licence is granted to the Wire trademark and its logos, which remain owned exclusively by Wire Swiss GmbH, and any use requires the express prior written consent of that company. For legal questions, this is a note about where to read, not advice.

Editorial conclusion

Adopt Wire Desktop if you want the Wire client on desktop and need the managed device behaviour, since the applockOverride flag lets an MDM administrator force app-lock on, overriding the team-level App-lock setting. Do not adopt it as the basis for a derivative product that connects to Wire servers, because the README states that an Open Source App may only be used and commercialized under the Wire Terms of Use, with restrictions on changing how the app connects, weakening security features and reusing the servers for other purposes. Verify first the Node version in.node-version, since the prerequisites require that exact version, and confirm the Electron and Yarn setup before you plan a build pipeline.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. wireapp/wire-desktop on GitHub