Understand MacBook battery drain over time — with battery power, sleep drain, CPU, RAM, swap, and app activity in one native macOS dashboard.
Русская документация · Installation · User guide · Metrics explained · Troubleshooting
Mac Battery Drain Tracker is a local MacBook battery monitor and system resource history tool built with SwiftUI and Swift Charts. It records minute-by-minute observations, compares battery and charger use, and helps investigate questions such as “Why does my MacBook battery drain so fast?” or “Why did it lose charge with the lid closed?”
The desktop app reads a local history written by a separate Swift collector. Recording can continue after the dashboard is closed. No account, cloud backend, analytics service, or third-party runtime package is required.
Project status: early-stage, source-build distribution. The interface defaults to English and can be switched to Russian from the globe menu in the toolbar. The choice is saved on this Mac. Documentation is available in English and Russian. The primary development hardware is an Apple silicon MacBook Pro. macOS 26+ and Swift 6.2+ are required; individual hardware sensors may be unavailable on other models. There is no notarized one-click installer in this repository.
- Battery drain while working: actual battery discharge power in watts, energy over a measured period, and estimated runtime at that workload.
- MacBook battery drain during sleep: complete closed-lid sessions, charge loss, percentage points per hour, and available background wake events.
- Memory use over time: used RAM, memory pressure, compressed memory, swap usage, and swap I/O.
- Apps associated with high load: CPU time, memory footprint, wakeups, disk activity, and time in the foreground.
- Battery versus charger behavior: charging, connected without charging, and battery discharge while an adapter is connected.
- Display-related power: built-in brightness and backlight power where supported by the hardware.
The app provides evidence for investigation. It does not claim to measure exact battery watts per application, repair a worn battery, or automatically optimize your Mac.
| Area | What is available |
|---|---|
| Overview | Current charge, battery capacity estimate, recent runtime estimate, historical CPU and RAM, energy for a selected period |
| Battery history | Discharge power, charge percentage, measured energy, power-source comparison, optional system and adapter sensors |
| Closed-lid history | Session duration, charge at both ends, charge loss, estimated hourly drain, sleep and background-wake context |
| Memory history | RAM, swap, compression, memory-pressure backgrounds, current memory composition |
| Interactive charts | Hover inspector, minimum/maximum/mean, automatic Y scale, scale from zero, drag-to-select a time interval |
| Compare two metrics | Shared time axis; shared scale for equal units or separately labeled scales for different units |
| Applications | Grouped apps and helpers, CPU, footprint/RSS, wakeups, disk I/O, foreground time, coverage information |
| Recording | Independent per-user LaunchAgent, approximately one sample per minute, pause/resume, CSV export |
| History storage | Immediate hourly JSONL writes, lossless XZ compression of completed hours, 200 MiB budget, storage warnings, no automatic history deletion |
| Faster history navigation | Incremental journal reading and up to 16 cached period/filter reports; calculations run off the main actor |
| Interface language | English by default, Russian available from the toolbar; selection persists on this Mac |
Each measurement is saved immediately. After an hour ends, its journal is compressed losslessly to standard XZ; the collector verifies decompression before removing the raw original. Existing daily journals remain readable. The 200 MiB budget counts actual stored journal bytes; reaching it pauses recording and preserves history. The overview shows used space, remaining allowance, and the measured compression ratio. Results depend on the data; no fixed compression ratio is promised.
The dashboard rereads only changed journal files and reuses up to 16 period/filter reports in memory. New, corrected, or deleted data invalidates the relevant cached statistics. Heavy calculations run off the main actor, and caches do not create another permanent history on disk. See storage and caching for details.
The battery page shows one card per battery state. Within it, Low Power, Automatic, High Power, and unknown modes appear side by side when measurements exist. Durations and averages remain separate for each mode. Different workloads affect power use, so these observations do not isolate the effect of the setting itself.
Hover over a chart to inspect the nearest recorded snapshot and its saved application groups. A point more than 45 seconds from the cursor is not presented as a contemporaneous measurement.
Drag across the chart to recalculate the mean and extrema for that interval. Averages are weighted by measured duration; sleep and discontinuities are excluded. Selection changes the chart summary, not every filter on the page. Select a custom date/time range to change the whole page.
Use Compare to add another series. A dashed line distinguishes the second metric. Two metrics in different units have independent scales: a visual crossing does not mean their values are equal or prove a causal relationship.
Use a permanent local folder. The app and background service remember this checkout's location.
Requirements: macOS 26 or later, an Xcode/Command Line Tools installation with Swift 6.2 or later and the macOS 26 SDK, Python 3, and Git. Apple silicon is the primary tested configuration; hardware-specific readings are not guaranteed on every Mac.
git clone https://github.com/Lemelson/mac-battery-drain-tracker.git
cd mac-battery-drain-tracker
# Run tests, compile the collector, and package the desktop app.
Scripts/build_all.shFor a first installation only, place the newly built collector in its runtime location and register the per-user background service:
install -m 755 verification/battery-study-v3 outputs/BatteryStudy/battery-study
mkdir -p outputs/BatteryStudy/data
chmod 700 outputs/BatteryStudy/data
python3 outputs/BatteryStudy/install.py
open MacBatteryDrainTracker.appInstalling the LaunchAgent enables collection at login. Do not run the first-install copy command over a running collector. For an existing installation, follow the update procedure, which checks a fresh sample and supports rollback.
If macOS requests access to the folder containing your checkout, review and approve it to let the app read its history. Locally ad hoc signed builds may request access again after rebuilding.
Two continuous snapshots are needed for most averages. Let the collector observe normal usage; there is no need to intentionally drain the battery to zero.
On battery power, discharge is estimated from battery current and voltage. Watts describe the rate of energy use; watt-hours describe energy accumulated over time. On an adapter, battery current describes the battery's own charging/discharging flow and is not the whole Mac's power consumption.
Runtime is an estimate from measured power and estimated useful battery capacity. It changes with workload. The live estimate requires at least five minutes of recent continuous battery operation and is disabled while plugged in, after gaps, or when readings are stale.
System CPU is normalized to all cores: 100% means all cores. An application's CPU is expressed in one-core units: 100% means one core. Helpers are grouped into their outer app where metadata is available.
Applications can be busy at the same time as a high system discharge reading without causing all that discharge. GPU, display, SSD, networking, and shared system work are not fully attributable to individual apps here.
Compressed memory is data packed inside RAM; the chart shows physical space occupied by the compressor. It is already included in used RAM. Swap is disk-backed memory on the startup drive. A small nonzero swap value is displayed in KB/MB rather than rounded to 0.0 GB.
A high used-RAM number alone does not establish memory pressure. Check pressure, compression, and ongoing swap activity together. Footprint and RSS are different measures; missing or partial process readings are labeled.
See the metrics reference for formulas, units, inclusion rules, and limitations, and the schema reference for stored fields.
The collector stores history locally under outputs/BatteryStudy/data/. It does not send telemetry or use a server.
It records resource measurements plus contextual metadata such as app names, bundle IDs and executable/app paths, foreground app, power source, display/lid/lock state, and time since input. It does not record window contents, screenshots, URLs, document titles, typed text, mouse coordinates, process command arguments, or network traffic.
Local does not mean anonymous or encrypted: the history can reveal app usage and activity patterns. Your operating system's backup or folder synchronization may copy it elsewhere. Files are restricted to the current user where possible. A 200 MiB journal budget pauses recording without deleting history.
The public repository excludes personal journals, generated reports, application binaries, local verification captures, and migration backups. Read the privacy and retention guide before sharing diagnostics.
| Guide | Contents |
|---|---|
| Installation and updates | Fresh clone, prerequisites, first recording, safe updates, stopping and uninstalling |
| User guide | Pages, time ranges, filters, chart interaction, useful investigation workflows |
| Metrics and methodology | Battery, CPU, memory, sleep, sensor limitations, interval calculations |
| Privacy | Collected metadata, exclusions, filesystem permissions, retention, sharing |
| Architecture | Swift package layout, collector/viewer separation, APIs, analysis pipeline |
| Troubleshooting | Empty charts, permission prompts, build errors, missing sensors, storage limits |
| Collector schema | JSONL fields, schema compatibility, process coverage |
| Contributing | Development commands, tests, review expectations, hardware reports |
| Changelog | Implemented changes through version 1.4.0 |
Is this an Activity Monitor replacement?
It focuses on persistent history and comparison across battery, memory, apps, and sleep sessions. Activity Monitor remains useful for inspecting current system activity.
Can it tell me exactly which app drained 20% of the battery?
No. CPU share is not battery share. App activity is evidence to guide a controlled comparison, not a per-app energy meter.
Why is swap zero while compressed memory is several GB?
Memory compression happens inside RAM and does not require the same amount of disk swap. A small swap allocation can also be below the display precision of a GB-only interface; this app uses adaptive units.
Does recording continue with the window closed?
Yes, when the separate LaunchAgent is enabled. Pausing recording in the app also disables its next-login startup. Sleeping Macs are not kept awake for sampling.
Can it recover last week's activity before installation?
No. Resource history starts when the collector runs. Available macOS sleep events may supplement sessions, but they cannot reconstruct missing CPU/RAM samples.
Does it work on Intel, every Apple silicon Mac, or older macOS?
The app currently targets macOS 26+, with primary validation on an Apple silicon MacBook Pro. Intel compatibility and individual private hardware sensors are not broadly validated. Missing readings remain unavailable rather than becoming fabricated zeroes.
Where do I download a ready-made app?
The documented distribution is currently a local source build. A generated .app depends on the adjacent project/collector setup and is not a standalone notarized installer.
swift test --disable-sandbox
python3 -m unittest discover -s outputs/BatteryStudy -p 'test_*.py'
Scripts/build_all.shTests cover interval continuity, clipped selection, CPU units, memory statistics, power conditions, sleep sessions, process attribution and parser behavior. CI builds and tests without installing the collector. Hosted CI is not proof that every physical hardware sensor is supported.
Apple Activity Monitor documentation explains system memory concepts. Stats provides menu-bar system monitoring, and macmon focuses on Apple silicon hardware monitoring. This project concentrates on local historical investigation of battery drain, sleep loss, and correlated app/resource activity. These links are references, not bundled dependencies or endorsements.
MIT — copyright 2026 Lemelson. Contributions and permitted reuse retain the copyright and license notice.