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.
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:
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:
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
NWPathMonitoras 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
- '
NWPathMonitoris 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.

