ZTools: an open source uTools alternative for macOS and Windows

What ZTools solves, and who it is aimed at

ZTools is an application launcher and plugin host. You press a shortcut, type part of an application name or a command, and either open something or run a plugin. The README describes it as an "Open Source Implementation of uTools", which sets the audience precisely: people who already use uTools and want the same interaction model under a licence they can inspect and fork.

The second audience is plugin authors. The project ships a global `ztools` object inside plugins that exposes notifications, simulated input and persistent storage, plus a `plugin.json` manifest format. Commands can be triggered by plain text, by regex, or by global hooks. That is a narrower and more concrete offering than "a launcher with extensions".

If you only want a fast application search box, the plugin system is weight you will not use. The README's feature list leads with pinyin search, regex matching, history tracking and pinned apps, so the launcher half stands on its own, but the project's identity is the platform half.

How the Electron process split and plugin data isolation work

The repository layout in the README shows three source trees: `src/main` for the main process, `src/preload` for preload scripts, and `src/renderer` for a Vue 3 interface. The main process holds `windowManager.ts`, `pluginManager.ts`, an `api/` directory of IPC modules and a `core/` directory containing the database and native modules. Plugins are loaded through a separate `resources/preload.js`, which is the mechanism that keeps plugin code away from the main process.

The README states that the project moved to LMDB for storage and describes "Data Isolation" as independent plugin data storage. Those two facts fit together: a key-value store with per-plugin namespaces rather than one shared settings file. The README does not document the on-disk path of the LMDB environment or the namespacing scheme, so you cannot tell from the README alone how a plugin's data is keyed.

Rendering uses a WebContentsView architecture, per the feature list. Native work is done in C++ through Node-API: clipboard monitoring, window management, and region screenshot on Windows. Note the asymmetry. Region screenshot is called out as Windows-only, while the headline claims native support for macOS and Windows. The README does not list which other native features are platform-gated.

Installing ZTools from Releases or building it with pnpm

The README gives two install paths. The recommended one is a prebuilt download from the Releases page: a `.dmg` or `ZTools-x.x.x-arm64-mac.zip` for macOS, and a `ztools-x.x.x-setup.exe` or `ztools-x.x.x-win.zip` for Windows. Pick the asset matching your architecture; the README names the arm64 macOS zip explicitly and does not name an Intel macOS asset.

To build from source, clone the repository and install with pnpm, then run the development task:

# Clone the repository
git clone https://github.com/ZToolsCenter/ZTools.git
cd ZTools

# Install dependencies
pnpm install

# Development mode
pnpm dev

The `dev` script is not a single process. In `package.json` it runs `concurrently` over `pnpm dev:main` and `pnpm dev:setting`, so an internal plugin named `setting` is built alongside the Electron app. If that second process fails, the launcher window may still appear while settings do not.

For packaged builds, the README lists per-platform scripts. The Linux variants exist even though the headline support claim is macOS and Windows:

pnpm build:mac    # macOS
pnpm build:win    # Windows
pnpm build:linux  # Linux (Default Arch)

Once running, the README says the main interface opens with `Option+Z` on macOS or `Alt+Z` on Windows, and that `↑` `↓` `←` `→` navigate, `Enter` confirms and `Esc` exits. Requirements are Node.js >= 18 and npm >= 9, and the README names macOS or Windows as the development environment.

Where ZTools is the wrong tool

The distribution story is the weak point. The README's support statement covers macOS and Windows, yet `package.json` carries `build:linux`, `build:linux:x64` and `build:linux:arm64` scripts. Build scripts are not a support commitment. A Linux build may compile and still miss the native modules that the README scopes to specific platforms, such as region screenshot on Windows. Nothing in the README says Linux is tested or supported for end users, so treating those scripts as a Linux release would be reading more into them than is there.

Plugin development is split across repositories. The description instructs contributors to fork `ztools-api-types` and `ztools-plugin-cli` if they intend to contribute code, and both appear as top-level entries in the repository. That means the type definitions your plugin compiles against are not necessarily the ones shipped in the app you installed. Version skew between the two is a real failure mode, and the README does not describe a compatibility matrix.

The README also does not document rollback, an update channel, or what happens to LMDB data across a version change. `dev-app-update.yml` and an `updater/` directory exist in the tree, so an update path is present, but the README is silent on its behaviour. If you need a documented downgrade procedure before deploying to a team, this project does not give you one yet.

ZTools compared with uTools and with a plain launcher

The direct comparison is uTools, and the README makes it for you by calling ZTools an open source implementation of it. The difference is licence and control, not feature parity. uTools is a closed product; ZTools is MIT, so you can read `pluginManager.ts`, fork it, and ship a modified build. What you give up is the polish that comes from a product with a single commercial owner. The README's roadmap shows a plugin market as completed, but it does not describe review rules, signing, or a submission process.

Against a launcher such as Alfred or a bare Spotlight-style search, the difference is architectural. Those tools expose their extension points through their own scripting conventions. ZTools instead runs plugins as web content behind a preload script, with a Vue renderer and a global `ztools` object, so a plugin is closer to a small web app than to a shell script. That is more capable for UI-heavy plugins and heavier for a one-line action.

The honest summary: ZTools competes on being forkable and on having a TypeScript plugin surface. It does not compete on documented platform coverage, and the README does not attempt to claim that it does.

Maintenance, licence and the cost of upgrading

ZTools is MIT licensed, with the `LICENSE` file at the repository root. MIT permits commercial use and modification, and it requires the copyright notice and permission notice to be retained in copies. That is the standard obligation; anything beyond it depends on the licences of dependencies such as Electron, Vue and LMDB, which the README does not enumerate. This is not legal advice.

The repository is not archived, and the last push was on 2026-08-29, which is the same timestamp as the v3.2.0 release. Before that, v3.2.0-beta.4 landed on 2026-08-28 and v3.2.0-beta.3 on 2026-08-27. The pattern is a short beta run followed by a stable tag, not a long soak. That is a reasonable cadence for a desktop app and a poor one if you need release candidates that sit for weeks.

Upgrade cost is concentrated in the plugin API. Because `ztools-api-types` and `ztools-plugin-cli` are separate repositories, a ZTools release can move while the types repository does not, or the reverse. The README does not state that the versions are pinned together. Budget for reading the changelog before each upgrade, and for re-running `pnpm typecheck` on any plugin you maintain, since the app's own `build` script runs `pnpm typecheck` before `electron-vite build`.

Editorial conclusion

Adopt ZTools if you want an MIT-licensed launcher whose plugin layer you can read and extend, and you are willing to develop against the ztools-api-types and ztools-plugin-cli repositories rather than expecting those to ship inside the main tree. Do not adopt it if you need Linux end-user builds or a plugin marketplace with published review rules, since the README documents neither. Before committing, verify the release assets for your platform and architecture on the Releases page, and confirm that the plugin API version your code targets matches the one in the release you install.

Frequently asked questions

Official sources

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