Introduction

On current Apple platforms, the safest answer is: do not try to prove “internet access” with a preflight reachability check alone. Apple’s guidance is to attempt the network request you actually care about, handle failure gracefully, and use modern APIs such as NWPathMonitor only to observe network conditions, not to guarantee that the internet is usable.

Why a Reachability Check Is Not Enough

A device can have Wi-Fi, a router, or some network path and still fail to reach your server. Captive portals, DNS issues, VPN policies, and backend outages all break the idea that one boolean “internet available” flag is trustworthy.

That is why an old-style SCNetworkReachability check against a dummy address is not a reliable internet test. It can tell you something about path availability, but it cannot prove your request will succeed.

The Modern Pattern

Use two layers:

1. try the real request with URLSession
2. observe path changes with NWPathMonitor if the UI needs network-state awareness

For user-initiated requests, attempting the request is usually the correct first step.

Use URLSession and waitsForConnectivity

If you want the system to wait until suitable connectivity appears instead of failing immediately, configure URLSession to do that.

1import Foundation
2
3let config = URLSessionConfiguration.default
4config.waitsForConnectivity = true
5
6let session = URLSession(configuration: config)
7let url = URL(string: "https://example.com/health")!
8
9let task = session.dataTask(with: url) { data, response, error in
10    if let error = error {
11        print("request failed:", error)
12        return
13    }
14    print("request succeeded")
15}
16
17task.resume()
18RunLoop.main.run()

This checks the thing that actually matters: whether your app can reach the endpoint it needs.

Use NWPathMonitor for Network State Changes

If your UI needs to react when connectivity changes, NWPathMonitor is the modern API.

1import Foundation
2import Network
3
4let monitor = NWPathMonitor()
5let queue = DispatchQueue(label: "NetworkMonitor")
6
7monitor.pathUpdateHandler = { path in
8    if path.status == .satisfied {
9        print("a network path is available")
10        print("expensive:", path.isExpensive)
11        print("constrained:", path.isConstrained)
12    } else {
13        print("no usable path right now")
14    }
15}
16
17monitor.start(queue: queue)
18RunLoop.main.run()

This is useful for adapting the interface, delaying optional sync, or telling the user why a transfer is waiting. It is not a promise that every host on the internet is reachable.

When Reachability Is Still Mentioned

You will still find older examples using SCNetworkReachability. That API is useful for some diagnostic scenarios, but it is not the right primary mechanism for proving internet access before every request. On modern iOS and macOS code, Network framework and real request handling are the better defaults.

Common Pitfalls

The biggest mistake is preflighting connectivity and then skipping the real request based on that guess. The guess can be wrong in both directions.

Another mistake is treating NWPathMonitor as an internet validator. It tells you about path status and properties, not whether a particular remote service is healthy.

A third mistake is showing blocking alerts for every connectivity fluctuation. Network conditions change often, so the UI should stay calm and recover automatically where possible.

Summary

• On iOS and macOS, do not rely on a preflight reachability check to prove internet access.
• Use URLSession to attempt the real request and handle errors normally.
• Use waitsForConnectivity when it makes sense for the system to wait and retry automatically.
• Use NWPathMonitor to observe path changes and network properties such as expensive or constrained access.
• Treat path monitoring as context for networking decisions, not as a definitive internet yes-or-no signal.