Handling Network Request Errors in the iOS Operating System

In iOS application development, network requests serve as the bridge connecting users to backend services; however, the unpredictability of network environments often leads to request failures. As developers, the primary task is to accurately identify the root cause of these errors. The URLSession framework in iOS provides a rich set of error types, primarily including NSURLErrorNotConnectedToInternet (not connected to an internet connection), NSURLErrorTimedOut (timed out), and NSURLErrorBadServerResponse (bad server response). Additionally, custom business logic errors—such as expired tokens or parameter validation failures—are frequently mixed in. Accurately categorizing these errors is the first step toward building a robust network layer; it determines whether to adopt retry strategies, display loading indicators, or present friendly prompts directly to users.
To avoid code cluttered with extensive if-else judgments, it is recommended to adopt the "Unified Interceptor" design pattern. In Swift, you can leverage the URLSession delegate protocol or custom coroutine wrappers to centrally handle exceptions. An excellent architecture should follow a "Capture - Analyze - Transform - Distribute" workflow: first capture underlying network exceptions, then attempt to parse specific error codes, and finally translate technical details into errors understandable by the business layer or UI feedback visible to users. This layered processing mechanism not only reduces repetitive code but also ensures consistent response behavior across the entire application regarding network fluctuations.

Implementing an Intelligent Retry Mechanism Based on Error Codes

For certain recoverable errors, such as transient timeouts or intermittent network disconnections, blindly throwing exceptions directly can degrade user experience. In these cases, an exponential backoff algorithm should be introduced to implement intelligent retries. In iOS development practice, you can monitor task status within the URLSession delegate method urlSession(_:task:didFinishCollecting:), or use a custom asynchronous function with Task for loop-based attempts.

Below is a simplified Swift example demonstrating how to encapsulate a network request function with retry logic:

import Foundation

func fetchUserData(with url: URL, maxRetries: Int = 3) async throws -> Data {
    var session = URLSession.shared
    var attempt = 0
    
    while attempt < maxRetries {
        do {
            let (data, response) = try await session.data(for: url)
            // Check HTTP status code to distinguish between 4xx and 5xx errors
            guard let httpResponse = response as? HTTPURLResponse else { throw NSURLErrorBadServerResponse }
            
            if (200...299).contains(httpResponse.statusCode) {
                return data
            } else if (400...499).contains(httpResponse.statusCode) {
                // Client error, usually no need to retry; throw business exception directly
                throw NSError(domain: "Network", code: 4, userInfo: [NSLocalizedDescriptionKey: "Server returned an invalid request"])
            } else {
                // 5xx or unknown errors; consider retrying
                throw NSURLErrorBadServerResponse
            }
        } catch let error as NSURLError {
            if error.code == .timedOut || error.code == .notConnectedToInternet {
                attempt += 1
                try? await Task.sleep(nanoseconds: UInt64(pow(2, Double(attempt - 1)) * 1_000_000_000)) // Exponential backoff
            } else {
                throw error
            }
        } catch {
            throw error
        }
    }
    
    throw NSError(domain: "Network", code: 5, userInfo: [NSLocalizedDescriptionKey: "Maximum retry attempts reached"])
}

Optimizing User-Facing Error Messages and Feedback

Ultimately, network request failures must reach the user; however, directly displaying technical terms like "connection failed" can cause frustration. Excellent error handling focuses not only on backend logic but also places significant emphasis on frontend experience. Upon catching an exception, differentiated feedback should be provided based on the error type: for timeout errors, display a message such as "Loading in progress, please wait" and automatically proceed to retry; for explicit business errors (such as 401 Unauthorized), guide users to re-login or refresh the page instead.

In practical UI implementation, this is typically accompanied by a global Toast notification component or modal dialog to present information. Furthermore, to reduce unnecessary consumption of server resources caused by ineffective requests, it is recommended that after detecting consecutive failures (e.g., three consecutive timeouts), retry attempts be proactively stopped and users prompted to check their network settings rather than having them wait indefinitely. This strategy respects user patience while ensuring the stability of the application system.