MacTools turns the macOS menu bar into a configurable tool shelf

A collection of menu bar tools in one application

MacTools describes itself as a free and open-source collection of native macOS menu bar tools, and the framing is a collection rather than a single utility. The site is mactools.ggbond.app, the primary language is Swift with SwiftUI in the repository topics, and the app requires macOS 14 or later with the note that some plugins need newer macOS versions or compatible hardware.

The README shows three panels that define what the collection covers. A System Status panel with live metrics, processes, device batteries and quick controls. An Activity Statistics panel with input counts, screen time, app usage and trends. And a Quick controls panel for displays, appearance, audio and power.

What makes it a collection rather than a dashboard is that these are menu bar panels. You arrange them in the menu bar, and they are there when you want them rather than in a window you have to open. The System Status panel screenshot is described as a panel with live metrics, processes, device batteries and quick controls, and the fan-speed-control topic tag suggests some of the plugins reach into the machine's cooling, which is the sort of thing that needs hardware that supports it.

The plugin marketplace is the extension mechanism and it is central to the design. You open the app, choose plugins in Settings then Marketplace, then arrange your menu bar panels, and permissions are requested as needed. The README says to browse dozens of plugins for productivity, displays, audio, cleanup and monitoring, with settings and shortcuts in one place.

The project is GPL-3.0 licensed with a LICENSE file, a LICENSES/ directory and a separate LICENSING.md at the top of the tree, and there is a Chinese README alongside the English one.

Panels you build, with widgets, controls and rows mixed in

The custom panel system is the part that makes MacTools more than a set of fixed widgets.

You mix live widgets, quick controls and feature rows in one panel. You drag to rearrange them, move them between panels, and choose each panel's icon. So the unit of configuration is not the panel but the item inside it, and the same widget can move from one panel to another.

The README describes some careful behaviour details that reveal how much attention went into the menu bar mechanics. The More and editing menus open on the first click from a background app, which is a specific complaint about menu bar apps that swallow the first click, and detail panels stay open during internal focus changes, which is the equivalent problem for panels that close when focus moves inside them.

The same care shows up in the settings descriptions. Plugin shortcut settings use the same separate section headings and native cards as other settings, without empty-section gaps or redundant navigation buttons. Custom settings workspaces use adaptive system backgrounds that coordinate with native settings cards, and search fields, inset previews and selected controls keep distinct visual roles in light and dark appearance. System Status settings use subtle metric row separators, aligned controls and a two-line metric header in narrow windows to keep names and value assignments readable.

These are small sentences about small details, and they are the difference between a menu bar app that feels native and one that feels like a web view in a rectangle. The screenshots referenced for the component library and the settings confirm the intent, since the component library image is described as a MacTools component library with a System Status widget preview.

Themes come from iTerm2 and Base16, and the icon can be animated

The custom themes feature goes further than a colour picker.

You can choose built-in palettes or import iTerm2 and Base16 or Base24 themes. That is an unusual set of sources. iTerm2 and Base16/Base24 are the theme sources the README names for import. Importing them means the menu bar can match a colour scheme you already use elsewhere, rather than asking you to pick sixteen colours again.

Light and dark themes are set separately, which is a real difference from apps that ship a single palette and hope for the best. You also choose between system glass and solid floating panels, which is the transparency decision, and you can personalise the menu bar icon with images or animations.

That last point is unusual for a menu bar utility. Most use a template image so the icon follows the system appearance automatically. MacTools lets you put an animated image in the menu bar, which is the kind of thing that is either exactly what you want or immediately annoying, and it is the kind of choice a native app can make that a browser extension cannot.

The dark theme gallery in the screenshots is described as showing palettes including System Default, One Dark, GitHub Dark and others, which gives a sense of the range on offer.

Workflows chain actions with triggers and failure handling

The automation and workflows feature turns the menu bar into something you can program.

You chain actions with delays and failure handling. Workflows can be triggered by schedule, calendar events, apps, power, displays or network changes, and there is a run history to review.

The trigger list is the interesting part. Schedule and calendar are obvious. The others are less so, and they explain why a menu bar application is a reasonable host for automation on macOS rather than a background daemon. Power and display changes are the moments when a desktop setup usually needs to do something, for example when a monitor is connected or the machine resumes from sleep. Network changes matter for the mobile user who switches between a hotspot and a home network. And app triggers are the classic automation entry point, the app you open determines what happens next.

Delays and failure handling make this more than a macro recorder. A workflow that steps through several actions needs to wait between them, and it needs to know what to do when one of them does not complete, which is the difference between an automation that works on a good day and one that works on all of them. The run history then tells you what actually happened, which is how you find out that the third step is the one that fails.

The automation editor is shown in the screenshots as a multi-step workflow, and the theme here is that the primitives come from the same panel system, so a workflow can invoke the same quick controls that the menu bar shows.

The command palette and the window switcher are the fast paths

The command palette is the keyboard route into everything. You can search actions, settings, workflows and plugins from it, with the shortcut Command-K inside MacTools, or you can assign a global shortcut to open it from anywhere.

There are also Action Grid, keyboard shortcuts, mouse mappings and trackpad gestures for frequent actions, and the palette can connect Apple Shortcuts, saved scripts and Run Links to your setup, with a documentation page for the URL scheme describing how Run Links work. The point of Run Links is that a MacTools action can be triggered from a URL, which is what makes the application scriptable from outside itself rather than only from its own window.

The window switcher is described in unusual detail, which suggests it is a heavily worked-on part. It keeps a compact toolbar in Cycle and Direct Key modes. Search Select uses that same toolbar with its inline search field expanded and focused. Cycle switches on shortcut release until you type or press Command-F, which opens search and keeps the chooser visible. All Windows sits beside the display filter and expands when an app scope is available, and Search, More and the grid and list control align to the right. Clicking the mode indicator cycles through Search Select, Cycle and Direct Key, the selection is saved, and the open chooser stays available for Enter or Escape. Window key assignments reserve Command-F for search, and closing Search clears the query and restores the previous mode while keeping scope and display filters.

In Direct Keys mode, Tab selects the next window and Shift-Tab the previous one, wrapping within the current results, and Return opens the selected window. Switching between grid and list keeps the selected window and the visible shortcut numbers in sync, including after scrolling or filtering, and the scrollbars hide when all the results fit.

Nightly builds, Homebrew, and the plugin build system

Installation is a Homebrew cask, and the project maintains a nightly channel alongside it.

brew install --cask mactools

MacTools checks for app updates automatically, and the README gives the Homebrew upgrade path for the greedy option:

brew update
brew upgrade --cask --greedy mactools

The nightly builds are distributed as MacTools-Nightly.dmg from a nightly prerelease. The README is clear about the implications: Nightly has separate preferences and plugins and can coexist with the stable app, it is intended for testing, and hardware controls still affect the same Mac. That last point is the important one, because a nightly build that changes a fan curve is still changing the fan curve of the machine you are sitting at.

The repository shows how the plugin system is built, and it is a substantial build system rather than a script. The Makefile is set up around Xcode, with a filtered xcodebuild wrapper at scripts/xcodebuild-filtered.sh, separate derived data for the test bundles so unsigned XCTest hosts stay out of the signed app build, a local plugin source directory and a generated plugin project config at Configs/GeneratedPlugins.yml, and a local plugin catalog written to build/LocalPlugins/catalog.dev.json. There is also a local icon gallery with its own catalog, a debug CLI path under the debug build products, and a plugin install directory under Application Support for the Dev build.

The top level holds Sources/, Plugins/, Tests/, Configs/, scripts/, docs/, site/, changes/ and a homebrew/ directory, along with project.yml for XcodeGen and a LocalConfig.sample.xcconfig. There are AGENTS.md, CLAUDE.md and GEMINI.md files, which is a sign of how the project expects AI tooling to be used in development. The releases list shows the project publishes nightly versions daily, with nightly-67-1 dated 2026-10-15 following nightly-66-1 and nightly-65-1 on the two previous days.

Editorial conclusion

MacTools suits a Mac user who wants system information, quick controls and small automations in one place without running several separate utilities, and it is the wrong tool if you only need one of those things, because a single purpose app is smaller and does less. Before installing, check that the plugins you want work on your macOS version and hardware, since the README says some plugins need newer macOS versions or compatible hardware. Verify first that you are comfortable with a GPL-3.0 application, and read the nightly build section before you install a prerelease, since the nightly app has its own preferences and plugins and can coexist with the stable one.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. mactools-app/MacTools on GitHub
3. Project website
4. README
5. Releases