Franz 5: the open-source Electron messaging client that Franz 6 replaced

What Franz 5 actually solves, and who the repository is for

Franz 5 puts WhatsApp, Slack, Telegram, HipChat, Hangouts and other web messaging services into a single desktop window. Each service runs as a web view inside one Electron process, so the user switches tabs instead of switching applications. The pitch is the app-switching tax: one window, many accounts, one place to check.

The repository is not that product anymore. The README states plainly that this repo holds Franz 5, the open-source predecessor of Franz 6, and that it is no longer the active product. Franz 6 is distributed from meetfranz.com, with a free tier and Franz Pro from €5 per month or a one-time lifetime license. So the audience for this code is narrower than the app's audience: people who want to read how a multi-service Electron client is structured, self-build it, or fork it under Apache-2.0.

One Electron process, many web services: the architecture in this repo

The shape of the project is visible from the repository layout. The Electron entry point is index.js, referenced by the main field in package.json, and the app id is com.meetfranz.franz. The source lives in src/, with shared UI split into Lerna packages under packages/ (the package.json depends on @meetfranz/forms, @meetfranz/theme and @meetfranz/ui as file: links). There is a separate uidev/ directory served by webpack-dev-server through the uidev script, which suggests the component library can be developed outside the full app.

Services are not hardcoded into the core. The README points to a separate Plugins repository for creating your own plugins and recipes, and asks questions to go to the community Slack at slack.franz.im. That separation is the important design decision: the host app handles windows, accounts, hibernation, themes and sync, while each service is described by a recipe. The cost is that the recipe format is defined elsewhere, so reading this repository alone will not tell you how a service is declared.

The build pipeline is Lerna plus Electron. package.json wires prestart to npm run rebuild, which runs npx electron-rebuild against node-mac-permissions, and start to electron ./build. Native modules are therefore rebuilt for the Electron Node version on every start, which is why the README warns that deleting node_modules is sometimes necessary before bootstrapping.

Installing Franz 5 and running the development app

The README gives two paths. For end users it points to meetfranz.com, and on macOS only it gives a Homebrew cask:

brew cask install franz

That command installs the packaged app, not this repository. If you want the source build, the README lists Linux distribution-specific dependencies in docs/linux.md first, then the native module rebuild, then the dependency install. Run these from the repository root:

npm run rebuild
npx lerna bootstrap

npm run rebuild fixes native modules to match the current Electron Node version. npx lerna bootstrap installs all dependencies and links the sibling @meetfranz packages. The README notes that if you previously ran npm install, it is sometimes necessary to delete node_modules before bootstrapping.

The development app needs two commands running simultaneously in different console tabs:

npm run dev
npm run start

npm run dev starts the Gulp development task; npm run start launches electron ./build. The README adds a warning worth reading before you file bugs: the development database will be reset regularly. For packaging, the README gives npm run build, which in package.json maps to npx electron-builder --publish onTag.

Where Franz 5 is the wrong tool

The clearest limitation is stated by the project itself: this is Franz 5, and it is no longer the active product. Anyone who wants Signal as a native client, built-in Franz Mail, the Franz Assistant or Privacy Shield will not find those here. The README lists them under what is new since Franz 5, and they belong to Franz 6.

The second limitation is the test story. The package.json test script is literally echo ';)' and the description field is a placeholder list of services, so the repository does not present an automated test suite as a gate. There is a jest.config.js and a test:watch script, so Jest is wired in, but the default test command does not run anything. If your reason for adopting a codebase is a verifiable test suite, this one does not advertise it.

The third is platform friction. The README's only documented install shortcut outside the source build is the macOS Homebrew cask, and Linux users are sent to a separate dependencies document before they can build. Windows build status is tracked through AppVeyor in the README badge, so the project did build on Windows, but the instructions in the README do not walk through it.

Franz 5 against a plain browser or a single-service client

The obvious alternative is not another aggregator but the services' own desktop clients, or pinned browser tabs. Slack, Telegram and WhatsApp all ship their own applications, and a browser profile with pinned tabs gives you the same web clients Franz 5 wraps, with the vendor's own update cadence and no Electron layer in between.

The difference in approach is where the state lives. A single-service client owns its session, its notifications and its updates. Franz 5 owns the container: it keeps multiple accounts per service, hibernates unused services, applies themes and syncs configuration, and delegates the actual messaging UI to the service's web page through a recipe. That is the trade. You gain one window and cross-service account management; you lose the vendor's native integrations and you inherit whatever the web client does inside an Electron web view.

For a developer choosing a codebase rather than an app, the comparison is between Franz 5 and building the container yourself. The repository gives you the Lerna package split, the recipe plugin model and the electron-builder packaging config. What it does not give you, per its own README, is the current product.

Maintenance status, licence and what a fork inherits

The repository is not archived. The last push was on 2026-06-12, which is recent enough that the code is not frozen, but the README's own framing matters more than the push date: Franz 5 is described as the open-source predecessor and no longer the active product. The release history supports that reading. v5.11.0 was released on 2025-04-09, v5.10.0 on 2023-09-03 and v5.9.2 on 2022-04-19, so the gap between 5.10.0 and 5.11.0 was roughly nineteen months.

Licensing is Apache-2.0, stated in both the README and the package.json license field. That is a permissive licence and it is the reason this repository has a life after the product moved on: you can read it, build it and fork it. Apache-2.0 also carries an explicit patent grant and requires that notices be preserved, but the practical implication for a fork is that you are maintaining the Electron, Lerna and native-module chain yourself. The pinned dependencies in package.json, including @babel/polyfill 7.4.4, @babel/runtime 7.4.5 and @electron/remote 2.1.2, are the upgrade surface. This is not legal advice; read LICENSE and package.json before you ship anything derived from it.

Editorial conclusion

Franz 5 is for developers who want to read or self-build an Electron multi-service messaging client, and for anyone who needs an Apache-2.0 codebase to fork. It is not the app to install if you just want to chat: the README points new users to meetfranz.com for Franz 6, and the repository says Franz 5 is no longer the active product. Before you invest time, run npx lerna bootstrap, then npm run dev and npm run start in two console tabs, and confirm the build still resolves against the pinned Electron and Lerna versions.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. meetfranz/franz on GitHub
3. Project website
4. README
5. Releases