# Network.framework NWPathMonitor and NWConnection versus SCNetworkReachability > Source-anchored research for Network.framework NWPathMonitor and NWConnection versus SCNetworkReachability. Run status: COMPLETED. Parent: [macOS App Sandbox Networking and Entitlements](https://llms-explorer.com/tree/macos-app-sandbox-networking/) · 4 facets · 8 facts · page: https://llms-explorer.com/tree/network-framework-nwpathmonitor-and-nwconnection-versus-scnetworkreachability/ ## 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](https://asciiwwdc.com/2018/sessions/715) ## 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](https://asciiwwdc.com/2018/sessions/715) - 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](https://developer.apple.com/forums/thread/105822) ## 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](https://developer.apple.com/videos/play/tech-talks/111378/) ## 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](https://developer.apple.com/forums/thread/808401) - 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](https://developer.apple.com/forums/thread/124396) - 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](https://developer.apple.com/forums/thread/698979) - 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](https://developer.apple.com/forums/thread/105822)