Guideline 2.4.2 power and resource efficiency for polling network monitors
Parent: Mac App Store App Review Guidelines for Sandboxed Utilities · Published reference · snapshot 2026-10-02
↓ Facts as markdownall context files
Source-anchored research for Guideline 2.4.2 power and resource efficiency for polling network monitors. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
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]
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]
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]
- 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]
- 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]
- 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]
- 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]
Children
- No children recorded.