Swift
Internet Connection
Network Monitoring
iOS Development
Swift Programming

Check for internet connection availability in Swift

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

In Swift, the modern way to monitor network availability is NWPathMonitor from Apple's Network framework. The important nuance is that "has a network path" is not exactly the same as "can reach the internet," so good app design separates local path monitoring from actual request success.

Use NWPathMonitor for Reachability State

NWPathMonitor reports whether the system currently has a usable network path and updates you when that status changes.

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

This is appropriate for enabling or disabling UI, deciding when to retry background work, or showing a lightweight offline banner.

Using the Monitor in a View Controller

The monitor should usually live in a shared service rather than inside every screen, but a small controller example makes the flow clear:

swift
1import UIKit
2
3final class ViewController: UIViewController {
4    private let monitor = NetworkStatusMonitor()
5
6    override func viewDidLoad() {
7        super.viewDidLoad()
8
9        monitor.onStatusChange = { [weak self] online in
10            DispatchQueue.main.async {
11                self?.title = online ? "Online" : "Offline"
12            }
13        }
14
15        monitor.start()
16    }
17
18    deinit {
19        monitor.stop()
20    }
21}

The callback from NWPathMonitor arrives on the queue you provide, so UI work should be dispatched to the main thread.

Path Availability Is Not Guaranteed Internet Access

This is the most important practical detail. A .satisfied path means the device has some route available. It does not guarantee that your backend is reachable, that DNS is working for your host, or that the user is not behind a captive portal.

If you need to know whether your app can actually talk to its service, make a lightweight request and treat that result as the final truth:

swift
1import Foundation
2
3func probeBackend() async -> Bool {
4    guard let url = URL(string: "https://example.com/health") else { return false }
5    var request = URLRequest(url: url)
6    request.timeoutInterval = 5
7
8    do {
9        let (_, response) = try await URLSession.shared.data(for: request)
10        guard let http = response as? HTTPURLResponse else { return false }
11        return (200...299).contains(http.statusCode)
12    } catch {
13        return false
14    }
15}

That request-based check is what matters for a feature that depends on your API, not just on general connectivity.

Older Reachability Approaches

Older projects often use SCNetworkReachability or a third-party Reachability wrapper. Those still exist in many codebases, but NWPathMonitor is the clearer modern choice for iOS 12 and later. If you are maintaining legacy code, there is usually no urgent need to rewrite everything immediately, but new code should prefer the Network framework.

Designing for Offline Behavior

A connectivity check should not be used as permission to skip error handling. Networks change between the time you check and the time you send the request. The best pattern is:

  • observe path changes for user experience
  • make real requests for real operations
  • handle request failures gracefully even if the monitor said "online"

That keeps the app correct even when the network state changes mid-flow.

Common Pitfalls

  • Treating NWPathMonitor as proof that the public internet or your backend is reachable.
  • Updating UIKit from the monitor callback queue instead of the main thread.
  • Starting a new monitor in every screen instead of centralizing the service.
  • Forgetting that connectivity can change after the check but before the request.
  • Using reachability as a substitute for proper request error handling.

Summary

  • 'NWPathMonitor is the standard Swift approach for monitoring network-path availability.'
  • A satisfied path is useful state, but it does not guarantee backend reachability.
  • Dispatch UI changes to the main thread from the path update callback.
  • Prefer one shared monitor instead of many independent monitors.
  • Real request success is the final check for features that need actual internet access.

Course illustration
Course illustration

All Rights Reserved.