macOS 12 users get system readings without a dashboard
Stats puts CPU, GPU, memory, disk, network, battery, sensor, Bluetooth, and clock information in the macOS menu bar. Each module can show a compact value or open a detail popup, which is a better fit for ongoing observation than keeping Activity Monitor visible. The current README requires macOS 12 Monterey or newer and excludes beta operating systems. That narrow platform target lets the app use native menu bar behavior, but it also makes Stats irrelevant to a mixed Windows and Linux fleet.
Privacy is unusually easy to understand. The README says Stats collects no telemetry or analytics. Its external requests go to api.mac-stats.com for update checks and the public IP feature, with GitHub as an update fallback. Blocking both hosts stops those functions rather than the local meters. There is no account to create and no hosted monitoring service to maintain. For a personal Mac, that is a cleaner bargain than sending hardware readings to a remote dashboard merely to see them at a glance.
The DMG is simpler than reproducing the source build
The supported install paths are a downloadable DMG and Homebrew. Manual installation means moving Stats into Applications, while Homebrew uses brew install stats. Uninstalling has more consequence because the supplied script quits the app, removes its data, and uses administrator privileges to delete the SMC launch daemon and privileged helper. Anyone testing fan controls should read that removal path first rather than assuming dragging the app to Trash removes every installed component.
Building or changing Stats asks for a different commitment. The codebase is Swift and tied to macOS frameworks. The README does not give a source-build recipe comparable to its end-user instructions. It also says the project is maintained by one person and generally rejects unsolicited pull requests. Prospective contributors should open an issue before writing code, except for translations and a small set of established contributors. MIT licensing permits a fork, but upstream collaboration follows the maintainer's rules.
What happened when we ran it
We did not run Stats at commit 85543cb. Our September 11, 2026 sandbox was a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM, and its harness had no supported Swift ecosystem. The repository also had no Dockerfile that could provide a project-defined environment. We therefore did not attempt installation, a build, or tests. There is no log tail or partial result to interpret because no supported command was available.
macOS 26 needs two settings before every display works
The README documents a macOS 26 privacy control that can leave Stats running with no visible menu icons. Users must allow the app under System Settings > Menu Bar. Closed issue 3120 records the missing-icon report and was resolved as a duplicate, which supports the maintainer's explanation without turning one report into a universal bug. This is a setup trap because enabled modules and widgets can look broken while the operating system is simply hiding the status items.
Desktop widgets have a separate limitation. Issue 2733 says repeated value updates put heavy load on macOS's chronod process, so Stats disabled widget communication by default on macOS 26. The README now tells users to turn on the macOS widgets option themselves. That switch restores data flow, but the underlying tradeoff still belongs to the user. A menu bar monitor should remain useful without widgets, so leave them off unless the desktop view earns its cost.
Sensors and Bluetooth carry the highest energy cost
Polling hardware is work, and Stats says so plainly. Its FAQ identifies Sensors and Bluetooth as the least efficient modules and says disabling them can reduce CPU use and power impact by up to 50 percent in some cases. That estimate comes from the project, not our Debian run. On a laptop, start with CPU, memory, disk, and network, then add sensor polling only when a temperature or device battery reading answers a specific question.
Some readings also depend on Apple's changing hardware interfaces. The README explains that CPU and GPU sensor labels describe thermal zones rather than individual cores. It says Apple changes SMC sensor keys with each new system-on-chip generation, so mapping values on new hardware takes time. Open issue 3562 reports questionable battery power figures on an M5 Mac, while v3.0.15 fixed an Intel charging calculation. Treat a surprising wattage or sensor name as something to cross-check, not an automatic diagnosis.
Fan control is included and explicitly unmaintained
The fan module is the clearest reason to choose another app. Stats calls fan control a legacy feature that receives no updates or fixes. The maintainer will accept contributed repairs but does not promise support. Open issue 3371 reports that control still failed on an M4 Mac after version 3.0.5, and the thread remained active in September 2026. Monitoring fan speed is one thing; changing a cooling policy requires more confidence than this module claims.
September 2026 activity is strong, while contributions stay controlled
GitHub recorded a last push on September 11, 2026, five days after v3.0.15 was published. The repository had 41,731 stars and 21 combined open issues and pull requests when fetched. Issue 3607, opened September 10, described network readings interacting with Little Snitch, while issue 3609 arrived the next day with a dual-GPU report. Recent code, releases, and user reports all point to an actively used project rather than a quiet download page.
That activity does not change the one-maintainer model. Stats is best for someone who wants configurable menu readings, accepts stable-macOS-only support, and will disable modules that cost too much energy. MenuMeters is a smaller open-source alternative, while Activity Monitor avoids a persistent third-party process. For most Mac users, Stats is the first free option to try. People seeking supported fan control or a routine upstream contribution path already have enough evidence to choose differently.