// the find
ggbond268/MacTools
A free and open-source collection of native macOS menu bar tools.
MacTools is a native macOS menu bar app (SwiftUI + AppKit, macOS 14+) that packs an enormous number of system utilities into a plugin-based architecture — fan control, display management, disk cleanup, trackpad gesture remapping, automation workflows, and ~40 more features. It targets power users who want a single app to replace a dozen separate menu bar utilities like TopNotch, Amphetamine, LinearMouse, and similar tools.
- Plugin architecture is genuinely well-structured: each feature lives in its own directory with Sources, Tests, Bundle entrypoint, and plugin.json manifest, making the codebase navigable despite the massive feature count.
- Test coverage is substantial and not just token tests — DiskClean alone has 30+ test files covering scanners, safety policies, staging, walkers, and executors separately, suggesting real unit testing discipline.
- The SMC/privileged helper pattern (e.g., BatteryChargeLimit, FanControl) correctly separates privileged writes into a separate signed helper rather than running the main app with elevated permissions.
- CI/CD pipeline is mature: separate workflows for build, release preparation, Homebrew cask update, plugin release, and GitHub Pages — this is not a solo project that ships by dragging a .app to a folder.
- The README is essentially a wall of marketing prose for every feature — no architecture overview, no explanation of how to build from source, and CONTRIBUTING.md is referenced but not surfaced. A developer wanting to contribute has to go digging immediately.
- macOS 14+ only requirement is a hard cut that locks out a significant portion of users still on Ventura (13), which shipped only ~2 years ago. Given many features wrap system APIs available on 13, this feels arbitrary.
- The plugin marketplace model (install/update/uninstall from within the app) introduces a runtime code loading surface that isn't explained — it's unclear whether plugins are separate signed binaries, dynamic libraries, or something else, which is a real security and sandboxing question for anyone evaluating adoption.
- No observable separation between the App Intent / Siri integration and the plugin system means any plugin API-breaking change likely silently breaks saved Shortcuts automations, and the README's vague 'stable action identity across display-name and parameter-schema changes' claim is unverifiable without seeing the migration code.