Does freezing apps really save battery?

We don’t guess. We measured it. This page documents the method, shows every chart, lists the exact hardware, and states the limits. If you’re skeptical — good: freeze a heavy app on your own Mac and watch the difference for yourself.

What “freezing” does

AppFreeze suspends a background app with SIGSTOP — the process is paused in place (CPU drops to ~0), not killed; SIGCONT resumes it instantly. The question this page answers: how much battery does that actually save? Every number below is a direct measurement of CPU package power via Apple’s powermetrics, or real battery discharge via IOKit — on real hardware, during real use.

The test rig (exact specs)

Machine: Mac17,3 — Apple M5, 10 cores, macOS 26.5.1 (fanless — this matters, see thermal note).
Load generator: a custom load generator we built — produces controllable CPU load (stable / bursty / chaotic curves) as a normal process that can be frozen.
Power: powermetrics (CPU package power, mW) + IOKit battery capacity (mAh) for the real-discharge test.
Conditions — honest: tests ran on a laptop during real user work (an active dev session + the OS in the background), not a clean-room. Our attribution subtracts that baseline (app_mW = total − idle baseline), so the background cancels out and we isolate the frozen app’s contribution. On a clean OS the saved fraction would be higher — our numbers are the conservative, real-world ones.

Test 2 — real battery discharge (%/hour)

Power in milliwatts is one thing; real battery life is what users feel. We measured actual battery drain (IOKit mAh) over 10-minute windows: app running vs frozen, with the same live background in both.

App running: 1332 mAh/h → frozen: 198 mAh/h. Freezing leaves only 15% of the drain — i.e. it removes ~85% of this app’s real battery cost.

Why we trust mAh over %: battery % has 1%-granularity; over 10 min that quantizes badly. The IOKit mAh reading is fine-grained, so we report mAh/hour as primary and treat the % as approximate. Stating this is the point — we show our error sources.

Test 3 — how much power a busy app actually draws

How much does a busy background app actually cost in watts? We swept CPU load 0.1→1.0 and measured power at each step — so “this app is using 30% CPU” can be put in real energy terms.

Per-app CPU% → app power, both modes. Normal mode is roughly linear (~30 mW per %CPU) until thermal limits; Low Power Mode saturates at a hard ~2.75 W ceiling.

Normal mode — and an honest surprise: power rises, peaks near 15 W, then falls at extreme sustained load. That’s thermal throttling on the fanless M-series — under a sustained all-core synthetic load it heats up and clocks down. Real background apps rarely sit there, but we show it rather than hide it.

Measured relationship: app_watts ≈ min(k·cpu%, ceiling) — k≈30 mW/%, ceiling≈15 W (normal); k≈9 mW/%, ceiling≈2.75 W (Low Power Mode). The heavier the background app, the more freezing it saves.

A note on realistic mixed sessions

We also simulated a mixed work session (pro work, browsing, video, idle, editing) with a forgotten background app, freezing it whenever it wasn’t in use. The repeatable finding: freezing saves energy during the phases you’re not using the app, and costs essentially nothing during the phases you are. The magnitude, though, varied run-to-run on this fanless machine (thermal coupling between back-to-back runs + short phases), so we deliberately do not headline a single session percentage — that would be a number you couldn’t reproduce, which is the opposite of the point. For reliable magnitudes see Tests 1–2.

We’ve since built a small repeatable rig for exactly this — a freezable synthetic “forgotten app” plus powermetrics sampling. It confirms the per-app picture: over a cycle where the app sits unused ~70% of the time, freezing recovers ~70% of that app’s own energy (in line with Tests 1–2). But the device-level session percentage stayed exactly as slippery as we expected — it’s dominated by what share of total power the forgotten app happens to be, and back-to-back runs on this fanless machine were noisy (one run’s idle baseline was contaminated and had to be discarded). So we still don’t headline a single mixed-session number: the honest answer is “it depends on what you leave running — and the big wins are heavy, forgotten apps.”

What does that variety actually look like? Below is an illustrative session: several background apps running at once, each with a different personality — a forgotten heavy app, a bursty browser, a light chat app, an idle syncer. It’s meant to build intuition for how tangled real-world load is — which is exactly why we report savings as a range, not a single precise number.

SIMULATIONillustrative load shapes · real power scale

This is a simulation, not a measurement. The activity shapes are synthetic — invented to show how varied background apps are. The vertical scale, though, is real: each curve’s power is derived from our measured Test-3 relation (≈30 mW per %CPU, capped near 15 W). The takeaway is the dashed line: whatever an app’s shape, freezing it drops it to the same ~0.4 W frozen floor (Test 1). The heavier and more “always-on” the app, the bigger the gap freezing closes.

Limitations (read this)

One machine. A fanless M5 Air. A fan-cooled MacBook Pro throttles differently and has a higher ceiling — the model needs per-chip-class calibration before we generalize.
CPU only. GPU / Neural Engine / disk / network aren’t modeled yet; heavy render/AI workloads will be added as a separate axis.
Display brightness was fixed but not logged precisely (it’s in the subtracted baseline).
Thermal artifact: back-to-back testing heats the fanless chip, compressing absolute power; isolated cold-start runs (Tests 1–2) show true magnitudes.
It’s an estimate, not a promise. Actual savings vary by app and workload — these are measurements of specific loads, and we never claim more precision than we measured.

Verify it on your own Mac

You don’t need our setup to check this. Open Activity Monitor’s Energy tab (or just watch your battery’s “time remaining”), note how much a heavy background app is costing you, then freeze it with AppFreeze and watch that number fall. A stopwatch and a couple of background apps are enough to see the effect for yourself.

Every figure on this page is a direct measurement on the machine above — not a marketing estimate.