How much battery does Xcode use on a Mac?

Measured 15 August 2026 · 217 windows on one Apple silicon MacBook — the machine this app was built on · reproducible with the script at the bottom

More than anything else on the machine, and it isn't close. Across the whole measured period Xcode accounted for 44.2 Wh — nearly three times what Chrome used on the same Mac over the same days, and Chrome is the app most people would have guessed.

The number that matters is 48.5, not 3.7

Xcode's median is modest because most of an editor's life is spent not compiling. The interesting part is the top of the distribution — a single window averaged 48.5 W, which is roughly twice what the entire machine typically uses (24.4 W). During a build, Xcode is the machine.

A third of the time it was over ten watts. That's the practical shape of development on battery: long cheap stretches of typing punctuated by short expensive stretches where the fans spin up and an hour of runtime disappears into a clean build.

166 processes

At its peak Xcode held 166 processes at once — median 7. Compilers, linkers, SourceKit indexing, simulators, test runners, preview agents, each its own line. This is the extreme case of the problem per-app measurement has to solve: most of those processes live for seconds. A tool that samples once a second and sums what it finds will simply miss the majority of a build's energy, because the majority of a build's processes were born and died between two samples.

WattMate credits that energy back through kernel resource coalitions — the kernel keeps a running total for a process tree, including children that have already exited. On our measurements that single change moved the named share of the CPU rail from roughly 20% to 91%. Without it, a build looks like a mysterious pile of unattributed watts; with it, it looks like Xcode.

What quitting it is worth

Computed per window, with the machine's floor as the lower bound rather than by subtracting medians:

An hour, typically — and up to two in the windows where a build was running. The figure is lower than the raw 44 Wh suggests for the same reason it always is: the floor doesn't leave when the app does. (On this machine the naive subtraction only broke in 16 of 217 windows, against 75% on our quieter Mac — a busy machine has plenty of headroom above its floor. More on that trap here.)

If you develop on battery

Three things follow from the shape of the data, not from opinion:

• Idle Xcode is cheap. Leaving the project open costs about as much as a browser tab. Quitting it between sessions buys you very little.
• Builds are the entire cost. If you need runtime, the lever is the number of clean builds, not the editor.
• Previews and simulators are part of the bill. They're in that 166 — and they keep working when you aren't looking at them.

What this does and doesn't prove

One Mac, one project. Xcode appears in only one of the two databases behind these pages — the other machine doesn't run it at all — so there is no second measurement to disagree with this one. A larger project, a slower machine or a different build configuration would move every number here.

And a disclosure: this is the Mac that WattMate itself was built and tested on, so the build load is ours. That makes the numbers real and specific, not representative. What generalises is the shape — near-free idle, very expensive builds, and an enormous process count — not the totals.

Measure your own

python3 Scripts/app-energy-report.py <database> Xcode

Or watch a build cost you runtime in real time: the trial ranks apps by actual watts, says what quitting the top one is worth in minutes, and re-measures two minutes later to check whether it was right.

Related: what Chrome costs · what Slack costs · how we count