Network.framework NWPathMonitor and NWConnection versus SCNetworkReachability
Parent: macOS App Sandbox Networking and Entitlements · Published reference · snapshot 2026-10-02
↓ Facts as markdownall context files
Source-anchored research for Network.framework NWPathMonitor and NWConnection versus SCNetworkReachability. 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.
Structure and components
- NWPathMonitor is part of Network.framework (iOS 12 / macOS 10.14+) and was introduced at WWDC 2018 as the replacement for SCNetworkReachability-style checks; Apple said it hoped all manual reachability uses would be replaced by the wait-for-connectivity model, with NWPathMonitor covering cases where that is insufficient. (medium confidence) [source]
How it works
- NWConnection's waiting state signals lack of connectivity, or a connectivity change during DNS/TCP setup, and is the Network.framework equivalent of waitsForConnectivity; after the connection is up, viability and better-path events report path changes (keep the old connection when viability is lost; open a new one before closing the old on better-path). (medium confidence) [source]
- Apple DTS says both SCNetworkReachability and NWPathMonitor are imperfect (false positives, false negatives, TOCTTOU), so neither should gate user actions; NWPathMonitor is appropriate only when there is no specific network operation to wait for, and the Retry button should not be disabled based on it. (medium confidence) [source]
Problems, failure modes and limitations
- Apple's Tech Talk 'Adapt to changing network conditions' states that preflight checks with SCNetworkReachability are deprecated in iOS 17.4, and advises: try to connect; use waitsForConnectivity on URLSessionConfiguration or the waiting state on NWConnection so the system retries automatically when conditions change. (medium confidence) (verified as of 2026-10-02) [source]
Facts and statements
- SCNetworkReachabilityGetFlags is synchronous yet can block the calling thread while name resolution completes, whereas NWPathMonitor is asynchronous and delivers its first status via callback, so callers must tolerate a delayed initial update. (low confidence) [source]
- Reading NWPathMonitor.currentPath right after creating the monitor returns .unsatisfied; Apple DTS says to set pathUpdateHandler and call start(queue:) first. The handler runs on the supplied queue, so UI work must hop to main. (low confidence) [source]
- NWPathMonitor interface reporting is coarse for a monitoring tool: a 2022 forum report describes availableInterfaces/isExpensive staying on the cellular interface after joining Wi-Fi (iOS, captive-style school Wi-Fi, unanswered), and secondary reports say VPN tunnels classify as NWInterface.InterfaceType.other and availableInterfaces order is not a documented route-preference signal. (low confidence) (verified as of 2022-01-01) [source]
- For interface type checks on a path, Apple DTS prefers repeated nw_path_uses_interface_type() calls over enumerating interfaces with nw_path_enumerate_interfaces(). (low confidence) [source]
Children
- No children recorded.