Why use NWPathMonitor instead of reachability, and how do you use connectivity information correctly?

Old reachability (SCNetworkReachability and third-party wrappers) answered “is there a route to a host?” and encouraged a bad pattern: check, then decide whether to try. NWPathMonitor from the Network framework reports the state of the network path as it changes: path.status (.satisfied, .unsatisfied, .requiresConnection), whether the path isExpensive (cellular or a personal hotspot) or isConstrained (Low Data Mode), which interfaces are available (usesInterfaceType(.wifi)) and whether it supports IPv4 or IPv6 and DNS. You create one, set pathUpdateHandler (or use its AsyncStream of paths in newer SDKs), give it a queue and call start(queue:), keeping a strong reference and calling cancel() when done. The handler fires once at start with the current state and then on every change.

Use it for UI and policy, not as a gate. A .satisfied path does not mean the server is reachable (captive portals, DNS failures, firewalls), and .unsatisfied may flip a moment later; so always attempt the request and handle the error, and use monitoring to show an “offline” banner, to retry when connectivity returns, to postpone large transfers on expensive or constrained paths, and to choose lower-quality media. For requests, the better primitive is URLSessionConfiguration.waitsForConnectivity = true: the system holds the task until a path exists and notifies you through taskIsWaitingForConnectivity, so you do not write the wait yourself. Mark requests that should not use cellular or expensive links with the configuration’s allowsExpensiveNetworkAccess and allowsConstrainedNetworkAccess. Test offline behaviour with the Network Link Conditioner and airplane mode, because simulated stubs never reveal these paths.