Record the environment
Log Mac model, chip, RAM, macOS, AppHalt version, tested app version, power source and starting battery level.
AppHalt Benchmark Lab · protocol v1.0
This public protocol defines how AppHalt tests app pausing: equal time windows, repeatable workloads, raw rows and explicit limits. It exists so future results can be checked rather than merely advertised.
It fixes the reporting rules before results are known. That makes it harder to select only favorable numbers. It also gives reviewers the exact fields needed to reproduce or challenge a future AppHalt test.
Reproducible protocol
The core comparison is the same app and workload in three states: active but idle, paused with AppHalt, and resumed.
Log Mac model, chip, RAM, macOS, AppHalt version, tested app version, power source and starting battery level.
Use the same open documents, tabs, project or call preparation in every run. Do not compare unrelated sessions.
Let startup, indexing and initial network bursts settle. Record unusual system activity in the notes.
Capture average CPU and Energy Impact over the full window, plus memory allocation and system memory pressure.
Alternate condition order where practical. Keep null, noisy and unfavorable runs rather than removing them silently.
Confirm the app returns, note reconnections or interruptions, and report any workflow side effect alongside system metrics.
Metrics
| Metric | Reason | Interpretation limit |
|---|---|---|
| Average CPU % | Shows processor activity across the fixed interval | A single instant is not representative; processor percentages fluctuate |
| Average Energy Impact | Apple’s relative indicator for current app energy use | It is not a direct battery-life percentage |
| App memory and memory pressure | Separates allocation from actual system memory stress | Pausing does not promise to free the app’s RAM |
| Workflow outcome | Records reconnects, stopped transfers or other user-visible costs | A lower metric is not useful if required work was interrupted |
| Battery level, only in long tests | Can support a controlled laptop scenario | Short tests, screen brightness and wireless activity make broad claims unreliable |
Planned evidence cases
These are registered test scenarios, not completed case-study results.
Foreground: one document editor.
Background candidates: browser, chat and music apps left idle.
Report: CPU, Energy Impact, memory pressure and missed notifications after resume.
Foreground: a call app that remains excluded.
Background candidates: unrelated browser, creative and developer tools.
Report: system metrics plus call stability; never pause the active call app.
Foreground: editor and required local services remain active.
Background candidates: unrelated communication and design apps.
Report: metrics plus any affected watchers, servers or helper processes.
Publication rules
Publish every valid run, not only the strongest result. Explain exclusions and preserve the original row.
A result applies to the recorded Mac, app versions and workload. It does not become a guarantee for every user.
Every dataset identifies the AppHalt version and date so old evidence is not presented as current indefinitely.
If an idle app was already doing almost nothing, the pause may show little measurable difference. That outcome belongs in the dataset.
Reconnects, stopped notifications and interrupted tasks are reported next to performance metrics.
Material changes receive a dated correction note rather than silently replacing the claim.
Measurement references
Evaluate it yourself
The public template lets you keep a comparable record instead of relying on a marketing percentage.
No guaranteed gain. Keep the result that your Mac actually shows.