<!-- llms-explorer concept facts · https://llms-explorer.com/tree/guideline-2-4-2-power-and-resource-efficiency-for-polling-network-monitors/ · pack 2026-10-02 · ~875 tokens -->

# Guideline 2.4.2 power and resource efficiency for polling network monitors

> Source-anchored research for Guideline 2.4.2 power and resource efficiency for polling network monitors. Run status: COMPLETED.

Parent: [Mac App Store App Review Guidelines for Sandboxed Utilities](https://llms-explorer.com/tree/apple-app-review-mac-utility-guidelines/) · 3 facets · 7 facts · page: https://llms-explorer.com/tree/guideline-2-4-2-power-and-resource-efficiency-for-polling-network-monitors/

## How it works

- WWDC22 'Power down' guidance: tell the system when background work is done, defer non-urgent work (discretionary URLSession, BGProcessingTask), and use low-priority pushes to avoid wakeups; the session is iOS-centred, so only the principle transfers to a Mac menu-bar app. (low confidence) — [source](https://developer.apple.com/videos/play/wwdc2022-10083)

## Measurements and reference values

- Apple advises setting timer tolerance to at least 10% of the interval for repeating timers (NSTimer setTolerance:, dispatch_source_set_timer leeway, CFRunLoopTimerSetTolerance) so the system can coalesce wakeups across processes; timers never fire early, only up to fire date plus tolerance. (medium confidence) — [source](https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/Timers.html)

## Facts and statements

- Guideline 2.4.2 text: design the app to use power efficiently; apps should not rapidly drain battery, generate excessive heat, or put unnecessary strain on device resources (examples: encouraging placing the device under a mattress while charging, excessive write cycles to the SSD); apps and third-party ads may not run unrelated background processes such as cryptocurrency mining. (medium confidence) (verified as of 2026-10-02) — [source](https://developer.apple.com/app-store/review/guidelines/)
- The rule sets no numeric polling interval, CPU or wakeup threshold; it is a qualitative standard (rapidly, excessive, unnecessary), so a reviewer judges it by observed behaviour. (low confidence) (verified as of 2026-10-02) — [source](https://developer.apple.com/app-store/review/guidelines/)
- Apple's Mac energy guide says every timer fire wakes the CPU from low-power idle states at an energy cost that adds up, and that sporadic work prevents resources reaching true idle, so a lot of energy is spent on little work; it advises batching tasks and running them less often. (medium confidence) — [source](https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/FundamentalConcepts.html)
- Apple's guide says not to use timers or sleep loops to poll for state changes; use event sources (dispatch sources) instead. For a network monitor this implies prefer SCDynamicStore / NWPathMonitor-style change notifications over fixed-interval probing where the state is observable. (low confidence) — [source](https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/Timers.html)
- A bundled Python (py2app) interpreter running a polling loop makes timer tolerance and idle behaviour the app's own responsibility; reviewers or Activity Monitor/Energy tab would show 'Energy Impact' and idle wakeups, which are the observable evidence for 2.4.2. (low confidence) — [source](https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/FundamentalConcepts.html)
