Does a menu bar app drain your battery? A measured answer
· 6 min read
Battery life gets worse, and the menu bar is a natural suspect: several things running all day that you never deliberately started. Some of them do cost you. Most cost nothing measurable, and the difference is not what people assume.
Here is how to find out rather than guess.
CPU percentage is the wrong measure
Activity Monitor’s CPU column is the number everyone reaches for, and it is a poor guide to battery.
What actually costs power is not cycles used but the machine being prevented from resting. A modern Mac spends most of its time in low-power states between the moments you ask it to do something, and dropping into and out of those states is where efficiency comes from.
So an app that uses a noticeable burst of CPU once an hour and then leaves the system alone is cheap. An app that wakes the processor every second to do almost nothing is expensive, and its CPU percentage will look negligible.
Use Energy Impact instead
Activity Monitor’s Energy tab has a column called Energy Impact that accounts for this. It weighs waking the processor, preventing sleep, and using the graphics processor alongside raw computation.
Sort by that column rather than by CPU. Leave the Mac otherwise idle for a few minutes and watch which processes accumulate a figure while you are not using them. That list is your answer.
The Avg Energy Impact column is more useful still, because it averages over the last eight hours rather than showing an instant, so a single spike does not dominate.
The behaviour that matters most: preventing sleep
The single most expensive thing a background app can do is stop the Mac resting. macOS tracks this explicitly:
pmset -g assertions
Real output from an idle Mac looks like this:
Assertion status system-wide:
BackgroundTask 0
ApplePushServiceTask 0
UserIsActive 1
PreventUserIdleDisplaySleep 0
PreventSystemSleep 0
ExternalMedia 0
Zeroes are what you want. A 1 against PreventUserIdleDisplaySleep or PreventSystemSleep means something is holding the machine awake, and the fuller output below that summary names the process responsible.
An app that holds one of those permanently costs more battery than anything it could do with the processor. Media players and video calls hold them legitimately while running. A status item holding one all day is a genuine problem.
Measuring properly
For a real figure, powermetrics samples power use per process. It needs administrator rights because it reads hardware counters:
sudo powermetrics --samplers tasks --show-process-energy -n 3 -i 5000
That takes three samples five seconds apart and prints per-process energy. Run it with the app in question running, quit the app, run it again, and compare. That is a measurement rather than an impression.
Do it while the Mac is otherwise idle, or the noise from whatever else is running will swamp the difference you are looking for.
What a well-behaved background app looks like
Three properties, all of which you can check.
It waits rather than polls. The system offers notifications for the things a status item usually cares about, so there is no reason to check on a timer. A polling app appears as steady low CPU that never stops.
It does not hold power assertions. Nothing in pmset -g assertions.
It does not use the network continuously. Check with:
nettop -P -l 1 2>/dev/null | head -20
An app generating traffic while you are not using it is doing something, and an app retrying a failed request in a loop is both using battery and telling you something is wrong.
Where Punchcard sits
Punchcard waits for the system’s notification that the frontmost application changed, rather than checking on a timer. Between switches there is nothing to do, and when you work in one application for an hour it does nothing for that hour.
It holds no power assertions, so it never stops the Mac sleeping. It has no networking code at all, so it cannot generate traffic or retry anything. Its one piece of real work happens at the closing time you set, when it prints a receipt of the day, and that takes a couple of seconds.
You do not have to take that on trust; the measurements above apply to it as much as to anything else. How to check what an app sends over the network covers verifying the networking claim, and how automatic time tracking works covers what it is doing between switches, which is nothing.
The honest summary
Most menu bar apps cost nothing you could measure. The ones that cost something usually do so for a specific, findable reason: a polling loop, a held power assertion, or a network request failing repeatedly.
Rather than removing status items on suspicion, spend five minutes with the Energy tab and pmset -g assertions. You will usually find that one app accounts for nearly all of it, and the others were innocent.
Questions
Does the number of menu bar icons matter by itself? Drawing an icon costs almost nothing. What each app does in the background is what matters, and that is unrelated to how many icons there are.
My battery got worse after an update, with no new apps. Check for reindexing. Spotlight rebuilds its index after major updates and can run for hours. It ends. Photos does something similar with libraries.
Is Energy Impact comparable between Macs? Not directly; it is a relative figure. Use it to compare processes on the same machine, which is the question you actually have.
Should I quit menu bar apps when on battery? Only the ones you have measured as costing something. Quitting apps that cost nothing achieves nothing, and quitting a tracker mid-day leaves a gap in the record.