I spent a day profiling my own menu bar app, expecting to shave a little off the edges. Almost none of the cost was where I assumed it was, and the most useful number turned out to be one I wasn’t looking at. If you’re trying to work out what any of these small always-running apps is doing to your battery, this is the shape of the answer.
The cost is never in the obvious place
Two things accounted for most of the recurring work. Neither was visible on screen.
Reading temperatures, a single line in the menu bar, meant 64 separate round-trips to a system service every couple of seconds, one per sensor, because that’s how many an M1 Max exposes. The number displayed is the hottest of a handful of CPU sensors; the rest were being read for a dashboard nobody had open.
The other was free disk space. There’s a macOS API for “available capacity” that quietly asks the system to work out how much space is purgeable, meaning caches it could evict under pressure. That’s a real computation in another process, and it was being requested thirty times a minute for a figure that changes by the hour.
Percentages flatter; wakeups tell the truth
Everyone quotes CPU percentage, including me. It’s the wrong headline for a background app. What actually costs battery is how often you wake the processor: a chip that gets to stay in a deep idle state sips power, and every wakeup drags it back out regardless of how little work follows. An app can show a tiny percentage and still be expensive because it never lets the machine settle.
So the figure I now watch is idle wakeups per second: 3.2 for Readout at a two-second refresh, which is close to the floor for anything that samples at all. It’s a number you can check on any app yourself, and it doesn’t care how flattering the percentage looks.
What happens when nobody’s looking
Here’s the question I’d put to any menu bar app: what does it do while your display is asleep? Most keep sampling cheerfully into a dark screen, measuring a machine nobody can see, on battery, all night. Readout now stops entirely and resumes within one tick of waking. Given how aggressive display sleep is on a laptop, that single change is worth more real-world battery than every micro-optimization I made that day.
Two memory numbers, not one
Memory deserves the same skepticism. Readout sits at 18 MB if you never open the dashboard. The first time you do, SwiftUI and the GPU machinery behind it add about 30 MB that macOS then keeps warm, settling into a 50–70 MB band. Both numbers are true; quoting only the first would be marketing. Any app that gives you one memory figure is describing one of its two lives.
Checking an app yourself
| Instead of | Do this |
|---|---|
| Reading the %CPU column | Note total CPU time, wait exactly a minute, read again, divide; the %CPU column is a decaying average that flatters and slanders by turns |
| Trusting an idle screenshot | Watch idle wakeups per second; tens are fine, hundreds are not |
| Assuming sleep is free | Sleep the display, wait, and check whether its CPU time moved at all |
Every figure here is from one M1 Max, and yours will differ. A fanless Air with fewer sensors is cheaper, and an Intel Mac takes a different path entirely. The method travels, though. An instrument’s first duty is not to disturb what it measures, and the only way to know whether it does is to measure the instrument.