Skip to content

Search

Match titles, tags, and descriptions. Arrow keys to move,Enter to open,Esc to close.

Open from the page (not while typing in a field):/·⌘KorCtrlK

    Permalink to this article

    macos

    Coolstead: Safety-first cooling for a Mac

    What it takes to design a native fan-control utility around bounded requests, invalid sensor data, reversible behavior, and macOS as the final safety layer.

    By

    Browse blog

    Notes, guides, and personal discoveries from things I build, enjoy, and learn.

    Deep Dive

    The simplest version of a fan-control app is also the version I do not want to build.

    Read a temperature. Pick a speed. Write the speed.

    That description leaves out nearly everything that makes hardware-facing software trustworthy: uncertain sensors, different fan ranges, fanless devices, privilege boundaries, lifecycle cleanup, and the fact that macOS already has a thermal policy that remains the final safety layer.

    Coolstead is my experiment in a calmer approach. It is a native menu-bar app that begins cooling earlier than the default macOS fan policy, applies a gradual curve, and returns control whenever balanced cooling is disabled.

    The product idea is “steady cooling.” The engineering idea is “bounded and reversible.”

    Earlier does not need to mean maximum

    Many fan utilities make maximum speed easy to reach. That can lower temperature quickly, but it is not the only useful strategy.

    Coolstead uses a gradual fan curve. As the thermal signal changes, the target moves smoothly instead of jumping directly to the final curve result. The goal is to respond sooner while keeping the experience quieter and less abrupt.

    The helper clamps every request twice:

    • to the fan’s reported minimum and maximum range
    • to no more than 75% of that reported range

    That second limit is a product decision, not a hardware guarantee. macOS remains responsible for the machine’s thermal safety. Coolstead is trying to influence comfort and sustained behavior inside a conservative envelope.

    Invalid input means no write

    Sensor data is not a promise.

    A reading can be missing, unsupported, stale, or clearly invalid. A control loop that treats every value as trustworthy creates the worst kind of failure: confident action based on bad input.

    Coolstead disables fan writes when the sensor state is not valid enough to support them. The monitoring surface can explain what is available, but the privileged path does not guess.

    This is a pattern I want in more automation: uncertainty should reduce authority.

    When a tool knows less, it should do less.

    Returning to automatic mode is part of every feature

    The most important action in a fan controller may be the one that gives up control.

    Coolstead returns every controlled fan to automatic mode when active cooling is disabled, when the connection is lost, or when the app quits. Cleanup is not an optional “reset” button hidden in settings. It is part of the lifecycle.

    That requirement affects architecture from the beginning. The app and helper need a narrow protocol. Controlled fan state needs to be tracked. Termination paths need to be testable. Failure cannot leave a previous manual target behind as if the product were still present.

    Reversibility is not a polish task. It is the safety model.

    Privilege should stay narrow

    Monitoring and writing are different capabilities.

    The app can build and run in monitoring-only mode with ad-hoc signing. Active fan control requires approval for a bundled privileged helper and a proper Developer ID identity.

    That separation makes local development safer and keeps elevated work concentrated in a much smaller surface. The UI does not become privileged simply because one operation requires it.

    The app also supports fanless Macs in monitoring-only mode. Unsupported control hardware should not turn the entire product into an error screen when useful thermal information is still available.

    Reverse-engineered hardware needs honest copy

    Coolstead uses reverse-engineered SMC behavior and builds on the MIT-licensed macos-smc-fan Swift package for transport and Apple Silicon fan-mode support.

    That means hardware support can vary by model and macOS version. The product should say that plainly.

    There is a temptation in system utilities to write confident marketing around uncertain platform behavior. I would rather make the limits visible:

    • Coolstead is not affiliated with Apple.
    • Hardware behavior varies.
    • A Developer ID is required for the privileged helper.
    • macOS remains the final thermal safety layer.

    Trust grows faster from a clear boundary than from an exaggerated promise.

    Small utilities contain systems lessons

    Coolstead is still an experiment, but it has already reinforced a useful checklist for software that can affect a machine:

    1. Bound every requested action.
    2. Ramp changes when abrupt movement is unnecessary.
    3. Treat missing data as a reason to stop.
    4. Keep privilege smaller than the product.
    5. Make return-to-default behavior automatic.
    6. Support monitoring when control is unavailable.
    7. Document uncertainty as part of the feature.

    Those rules apply beyond fan control. They apply to deployment automation, AI agents, database tools, and any system where a helpful action can become expensive when context is wrong.

    The full project summary is in the Coolstead portfolio entry.

    Share this piece
    LinkedInXWhatsApp

    Powered by GitHub Discussions — sign in with GitHub to join the conversation, orreply on GitHub.

    Related writing

    Keep reading in the same thread.

    More writing from a similar lane — overlapping topics, tooling choices, and the tradeoffs behind the article you just read.

    Browse all posts