Stats for macOS: a menu bar monitor whose sensors are thermal zones

Three install routes, and the one that needs a second machine

Stats is a macOS system monitor written in Swift that lives in the menu bar, MIT licensed, with a homepage at https://mac-stats.com. Three routes are documented. The manual route downloads `Stats.dmg` from the releases page, and you open it and move the app to the application folder. Homebrew takes one line:

brew install stats

The third route exists for machines with no screen. Over SSH you run:

curl -fsSL https://cdn.mac-stats.com/install.sh | bash

The script installs the app, enables the Remote module and prints a URL with an authorization code. You open that URL on any device, sign in to your System Stats account, and the machine is authorized. Stats then streams its metrics to that account, and it is registered to launch at login and to restart if it stops. That turns a menu bar app into a remote agent, which is a different product from the one most people download.

A headless install waits for the first login

The SSH route has a precondition the README states plainly: the Mac needs an active user session, and a locked screen is fine, but on a fully headless machine Stats will start at the next login. The script therefore finishes without a working agent. On a Mac mini or a build box with no console attached, you get the app installed and the Remote module enabled, then nothing streams until somebody logs in.

That makes the headless path a two step job with a human in the middle: install over SSH, then visit the printed URL from a phone or laptop, then log in on the Mac once. The README does not say how long the authorization stays valid, whether it survives a reboot, or what the account can see beyond metrics, so the credential question is unanswered by the project. If your fleet is machines that never see a login, this route does not cover it.

macOS 26 hides every icon until you allow it

The most common way Stats looks broken is not a bug in the app. macOS 26 introduced a privacy control under System Settings, Menu Bar, and apps must be explicitly allowed there before they can display menu bar items. The failure signature is specific: Stats is running, at least one module is active, a widget is enabled, and no icon appears at all. The fix is to open System Settings, then Menu Bar, and toggle Stats on. The README points at issue 3120 for the background.

A second, older surprise sits next to it. macOS decides the order of menu bar items, not Stats, and the order can change after the first reboot following an install. Reordering is a system gesture: hold the command key, drag the icon, release. That works from macOS Mojave, version 10.14, upward. So a fresh install can move your icons once, and the fix is a drag rather than a preference inside the app.

Widgets are off by default because chronod cannot keep up

Desktop widgets do not populate until you turn them on yourself, and the reason is a system process rather than a setting you missed. The README points at `chronod`, the system process that carries communication between the app and its widgets, and says that high data load in `chronod` is why communication is disabled by default on the Stats side. The remedy is in Stats Settings, where the `macOS widgets` option has to be enabled. Issue 2733 holds the details.

The consequence for a user is a second permissions ritual after the Menu Bar one: install, allow the menu bar item, then find the widgets toggle. Neither is discoverable from the app icon, because in the first case the icon is the thing that is missing, and in the second the widget is blank with no error. Anyone deploying Stats across several Macs should write both toggles into the setup, since a user who cannot see the icon has no way to find the widget setting.

Sensors are thermal zones, and the labels oversell them

Stats reads hardware values through the SMC, and the README is direct about a misreading people arrive with. CPU and GPU sensors are simply thermal zones on the chip, with no relation to the number of cores or to any specific core. A modern CPU is divided into clusters, efficiency and performance, and each cluster holds several temperature sensors, so a reading labelled CPU Efficient Core 1 is one sensor inside the efficiency cluster, not the temperature of one core. Treating those labels as per core values produces numbers that look precise and are not.

The deeper limit is churn. Apple changes the sensor keys with each new SoC, so mapping SMC values to the right sensors takes time, and the README asks anyone who knows the correct mapping for Apple Silicon to get in touch. Fan control sits in the same corner. It is in legacy mode, receives no updates or fixes, and stays in the app only because it works acceptably on older Macs. The author is open to a pull request for it and equally clear about having no time to support it.

No telemetry, but two external calls and your public IP

Stats collects no telemetry and no analytics. It does make external requests, and the README names all of them: https://api.mac-stats.com for update checks and for retrieving your public IP address, and https://api.github.com as a fallback for update checks. The author's reasoning for the first is that the public IP lookup should not go to a third party provider, so the server is his own.

If that bothers you, the README offers two routes rather than a switch. Propose a pull request that lets those features work without an external server, or block both hosts with a network filtering app. The README then names the cost of blocking them plainly: no updates, and no public IP in the network module. That is the trade, and for an air gapped or tightly filtered Mac it is the only decision to make before install, because unblocking later is a policy change rather than a preference.

Every build is notarized, stapled and version-bumped

The repository is a Swift package laid out as `Kit/`, `Modules/`, `Widgets/`, `SMC/`, `LaunchAtLogin/`, `Tests/` and `Stats.xcodeproj/`, with a Makefile that chains the whole release. Its target list runs clean, next-version, archive, notarize, sign, verify, prepare-dmg, prepare-dSYM and open, so a build bumps the version and opens the app as part of the same run. Notarization is one line of that chain:

xcrun notarytool submit --keychain-profile "AC_PASSWORD" --wait $(ZIP_PATH)

Signing then staples the app and runs `spctl` against it, and the export step reads `exportOptions.plist` with the bundle id `eu.exelban.Stats`. Read that keychain profile name as a fact about the maintainer's setup rather than something you can copy. A fork has no `AC_PASSWORD` profile, so it can build and test but cannot produce a notarized release the way he does.

Uninstall needs an administrator, and patches land twice a week

Removal is a bundled script rather than a drag to the trash, and it asks for administrator privileges because of the SMC helper:

sh /Applications/Stats.app/Contents/Resources/Scripts/uninstall.sh

Support is narrow on the platform side. Stats requires macOS 12, Monterey, or newer, and beta versions of macOS are not supported, only stable releases. Older systems are pointed at a separate legacy build at https://mac-stats.com/downloads. On the release side, v3.0.17 landed on 2026-09-20, v3.0.18 on 2026-09-27 and v3.0.19 on 2026-09-29, and the last push to the repository was on 2026-09-29. Patches arrive faster than documentation, so the FAQ entries, not the version list, are where the current behaviour is described.

Editorial conclusion

Use Stats if you want CPU, GPU, memory, disk, network, battery, sensor and Bluetooth readings in the menu bar of one Mac you sit in front of, and you are on a stable macOS 12 or newer. Do not rely on it for fan control, per core temperatures, or a server with no user session, because the README marks fan control as legacy with no fixes, says the sensor keys change with every new Apple SoC, and says a headless install waits for the next login. Before installing, check the two things that decide your experience: whether you will grant Location Services for the Wi-Fi network name, and whether you mind the app calling api.mac-stats.com for update checks and your public IP.

Frequently asked questions

Official sources

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