Introduction

On modern iOS, the easiest way to observe network availability is NWPathMonitor from the Network framework. It tells you whether the device currently has a usable network path, which is much better than older reachability patterns, but it still does not guarantee that your specific server is reachable.

Use NWPathMonitor for Reachability State

NWPathMonitor gives you a stream of path updates as the network changes. You can inspect whether the path is satisfied and whether the connection is using Wi-Fi, cellular, or another interface.

1import Foundation
2import Network
3
4final class ConnectivityMonitor {
5    private let monitor = NWPathMonitor()
6    private let queue = DispatchQueue(label: "ConnectivityMonitor")
7
8    var onChange: ((Bool) -> Void)?
9
10    func start() {
11        monitor.pathUpdateHandler = { [weak self] path in
12            let isOnline = path.status == .satisfied
13            DispatchQueue.main.async {
14                self?.onChange?(isOnline)
15            }
16        }
17        monitor.start(queue: queue)
18    }
19
20    func stop() {
21        monitor.cancel()
22    }
23}

This is usually enough to show offline UI, disable sync buttons temporarily, or decide whether to retry queued work.

Understand What It Does Not Tell You

NWPathMonitor answers "does the device currently have a usable network path?" It does not answer "is my backend healthy?" or "can I reach this exact URL?" Those are application-level questions, and the only reliable way to answer them is to make a real request.

For example, if your app depends on one API, pair reachability state with an actual probe or the normal request flow:

1import Foundation
2
3func checkServer(completion: @escaping (Bool) -> Void) {
4    let url = URL(string: "https://example.com/health")!
5    let task = URLSession.shared.dataTask(with: url) { _, response, error in
6        let httpResponse = response as? HTTPURLResponse
7        let ok = error == nil && (200...299).contains(httpResponse?.statusCode ?? 0)
8        completion(ok)
9    }
10    task.resume()
11}

This second step matters because a device may be online while your API is down, blocked, or misconfigured.

Update the UI Safely

NWPathMonitor callbacks do not arrive on the main thread, so any UI work must be dispatched back to the main queue. That is why the example above wraps the callback with DispatchQueue.main.async.

In a UIKit controller, a simple usage pattern looks like this:

1import UIKit
2
3final class ViewController: UIViewController {
4    private let monitor = ConnectivityMonitor()
5
6    override func viewDidLoad() {
7        super.viewDidLoad()
8
9        monitor.onChange = { [weak self] isOnline in
10            self?.title = isOnline ? "Online" : "Offline"
11        }
12        monitor.start()
13    }
14
15    deinit {
16        monitor.stop()
17    }
18}

This keeps the reachability logic separate from the view code and avoids stale callbacks.

Prefer Observation Over Gating

One common mistake is blocking every network request until a reachability monitor reports "online." In practice, the network state can change between the time you check it and the time the request is sent. A more robust design is:

• observe connectivity for user experience
• attempt the request anyway
• handle the real request error cleanly

That pattern produces better apps because it does not rely on reachability as a perfect predictor.

Common Pitfalls

• Treating NWPathMonitor as proof that your backend is reachable. It only reports path availability on the device.
• Updating UI directly from the path callback without hopping back to the main thread.
• Forgetting to keep the monitor alive. If it is deallocated immediately, you will never receive updates.
• Using reachability as a hard gate before every request instead of handling actual request failures.
• Relying only on the simulator. Cellular, captive portal, and real network transitions are much easier to validate on a device.

Summary

• On modern iOS, NWPathMonitor is the simplest built-in way to observe connectivity changes.
• Use it to drive UI and retry behavior, not as a guarantee that your server is healthy.
• Make a real request when you need to know whether a specific endpoint is reachable.
• Dispatch UI updates back to the main queue.
• Treat connectivity checks as helpful signals, not as a substitute for proper network error handling.