Optimizing Network Calls with URLSession in iOS Development

Efficient network communication is the backbone of modern iOS applications. Users expect fast, reliable data exchange whether they are browsing social feeds, streaming media, or syncing content in the background. Apple’s URLSession framework provides a powerful, flexible API for managing HTTP requests, data transfer, and background tasks. When used correctly, URLSession can dramatically improve app performance, reduce battery drain, and enhance user experience. This article explores advanced strategies and best practices for optimizing network calls using URLSession, from configuration and caching to concurrency and error handling.

Understanding URLSession and Its Components

URLSession is part of the Foundation framework and replaces the older NSURLConnection. It is designed to handle asynchronous network operations without blocking the main thread. At its core, URLSession revolves around three key concepts:

  • URLSession – The session object that coordinates a group of related network tasks.
  • URLSessionTask – The actual work unit, such as data task, upload task, or download task.
  • URLSessionConfiguration – Defines behavior for the session, including caching, timeouts, cookies, and TLS settings.

By choosing the appropriate session type (default, ephemeral, or background) and fine‑tuning configuration, developers can control exactly how network calls behave under varying conditions.

Apple’s official documentation provides a comprehensive overview: URLSession – Apple Developer Documentation.

Configuring URLSession for Optimal Performance

Choosing the Right Session Configuration

URLSession offers three built‑in configurations:

  • .default – Uses the global disk‑based cache and credential store. Ideal for most standard data requests.
  • .ephemeral – No persistent cache or cookies. Useful for private browsing or test environments.
  • .background – Designed for long‑running uploads and downloads that continue even when the app is suspended or terminated.

For most production apps, a custom session configuration based on .default with specific overrides yields the best balance between performance and resource usage.

Timeouts and Waits for Connectivity

Setting appropriate timeout intervals prevents users from waiting indefinitely on slow networks. Key properties include:

  • timeoutIntervalForRequest – Time to wait for additional data after receiving a response (default 60 seconds). For small payloads, consider lowering this to 10–15 seconds.
  • timeoutIntervalForResource – Maximum time for the entire request, including retries (default 7 days). Reduce to a few minutes for real‑time operations.
  • waitsForConnectivity – When set to true, the system defers the task until a suitable network is available, rather than failing immediately. This is essential for background sessions and user‑facing apps that should avoid transient errors.

Example of a configuration tailored for responsiveness:

let config = URLSessionConfiguration.default
config.timeoutIntervalForRequest = 15
config.timeoutIntervalForResource = 120
config.waitsForConnectivity = true
config.urlCache = URLCache(memoryCapacity: 50_000_000, diskCapacity: 100_000_000)
let session = URLSession(configuration: config)

By default, URLSession uses the server’s cache directives (e.g., Cache-Control). For more control, set requestCachePolicy on the configuration:

  • .useProtocolCachePolicy – Respect server headers.
  • .returnCacheDataElseLoad – Serve cached data first; fall back to network.
  • .reloadIgnoringLocalCacheData – Always fetch fresh data.
  • .returnCacheDataDontLoad – Offline mode.

Cookie acceptance can be toggled via .cookieAcceptPolicy. For APIs that do not require cookies, using .never reduces overhead and storage writes.

Advanced Caching Strategies

URLCache – The Built‑In Cache

URLCache stores response data in memory and on disk. Tuning its capacities is critical. A memory cache of 50‑100 MB and disk cache of 100‑200 MB works well for many apps. For static resources like images, consider larger disk limits. The cache obeys standard HTTP caching headers (ETag, Last‑Modified, Cache‑Control).

To invalidate a specific URL programmatically:

URLCache.shared.removeCachedResponse(for: request)

Incorporating NSCache for Custom Objects

For parsed model objects or images, combine URLCache with an in‑memory NSCache. This reduces repeated decoding and I/O. Key‑off the URL string and evict objects under memory pressure. This two‑tier cache is a proven pattern in production apps.

Handling Stale Data

Sometimes servers send Cache-Control: no-cache. Your app can still cache responses using a custom policy: store the data locally (e.g., Core Data, UserDefaults) and implement a refresh interval. Combine with waitsForConnectivity to seamlessly serve stale data when offline.

Leveraging Background Sessions for Long‑Running Tasks

Background sessions allow downloads and uploads to continue after the app is suspended or terminates. They are essential for tasks like:

  • Downloading large media files.
  • Uploading user‑generated content (photos, videos).
  • Syncing data when the app is in the background.

Configuration steps:

  1. Create a URLSessionConfiguration.background(withIdentifier:) with a unique identifier.
  2. Set sessionSendsLaunchEvents to true to wake the app on completion.
  3. Implement URLSessionDelegate methods (didFinishDownloadingTo, didCompleteWithError).
  4. Handle the completion block in AppDelegate using a background session identifier.

Background sessions have limitations: they must be created with a delegate, and the data is delivered via file URLs. Also, only one background session per identifier should exist at a time.

Watch Apple’s WWDC 2019 session “Advances in Networking, Part 2” for detailed guidance: Advances in Networking – WWDC 2019.

Implementing Request Throttling and Queueing

Using Operation Queues for Concurrency Control

URLSession tasks are inherently asynchronous, but you may want to limit the number of simultaneous network calls to avoid overwhelming the connection. Set maxConcurrentOperationCount on a custom OperationQueue and use it as the delegate queue for the session:

let operationQueue = OperationQueue()
operationQueue.maxConcurrentOperationCount = 4
let session = URLSession(configuration: config, delegate: nil, delegateQueue: operationQueue)

Debouncing Rapid‑Fire Requests

When users type in a search field, it’s wasteful to fire a network call on every keystroke. Implement debouncing with a timer or Combine’s debounce operator. Cancel the previous task before starting a new one to prevent out‑of‑order responses.

Batching Independent Requests

Combine multiple requests into a single HTTP call when the API supports it (e.g., GraphQL, batch endpoints). For REST APIs, use URLSession’s dataTask with a serial queue to process responses in order. Consider grouping critical requests into one session to reuse connections (HTTP/2 multiplexing).

Using Modern Swift Concurrency with URLSession

Async/Await Syntax

iOS 15+ introduced async/await support directly in URLSession. This dramatically simplifies networking code, replacing cumbersome closures with linear‑looking code that is easier to read and debug:

do {
    let (data, response) = try await session.data(from: url)
    // Process data
} catch {
    // Handle error
}

This eliminates callback pyramids and makes error handling straightforward with try/catch. Under the hood, URLSession manages threading, keeping the main thread free.

Structured Concurrency and Cancellation

Use Swift’s Task and TaskGroup to launch multiple network calls concurrently:

async let (userData, _) = session.data(from: userURL)
async let (feedData, _) = session.data(from: feedURL)
let (user, feed) = try await (userData, feedData)

Cancelling a parent task automatically cancels all child tasks – perfect for view controllers that go off‑screen.

Migrating Legacy Delegate Code

Existing delegate‑based sessions can be wrapped with URLSession.bytes(from:delegate:) to adopt async streams, but for new development, prefer the data(from:) API. Combine both approaches when incremental migration is required.

Handling Errors and Retries

Graceful Error Handling

Not all network errors are equal. Distinguish between recoverable errors (timeout, no connectivity) and permanent ones (invalid URL, authentication). Implement a delegate method for session‑level errors and task‑level errors separately.

Apple’s URLError provides granular error codes (.timedOut, .notConnectedToInternet, .networkConnectionLost). Use these to decide on retry strategies.

Exponential Backoff with Jitter

When a retryable error occurs, wait before retrying – and increase the delay each time. Add random jitter to prevent the “thundering herd” problem. A typical pattern:

  1. First retry after 2 seconds.
  2. Second retry after 4 seconds (or 4 ± random).
  3. Third retry after 8 seconds.
  4. Maximum retries: 2–3 for user‑facing requests, more for background syncing.

Use a custom retry wrapper that checks the error type and implements the backoff calculation.

Network Reachability Awareness

Combine URLSession with the Network framework’s NWPathMonitor to avoid retrying when no network is available. Pause retry queues when connectivity is lost and resume once it returns. This saves battery and reduces frustration.

Security Best Practices

Always Use HTTPS

Apple enforces App Transport Security (ATS) by default, which requires HTTPS connections. Do not disable ATS except for specific, well‑reasoned exceptions. Use NSAppTransportSecurity in Info.plist only for development.

Certificate Pinning

For sensitive apps, pin the server’s certificate or public key to prevent man‑in‑the‑middle attacks. Implement URLSessionDelegate’s didReceive challenge method:

func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge) async -> (URLSession.AuthChallengeDisposition, URLCredential?) {
    guard let serverTrust = challenge.protectionSpace.serverTrust else { return (.cancelAuthenticationChallenge, nil) }
    // Validate trust and pinning logic
    return (.useCredential, URLCredential(trust: serverTrust))
}

Consider using a third‑party library like TrustKit for easier management, but always verify the pinned identity matches your server’s certificate.

Protecting API Keys

Never embed API keys directly in code. Store them in the Keychain or fetch them from a secure server. URLSession automatically disables arbitrary loads, but ensure your custom headers are not logged inadvertently (URLProtocol debugging may leak them).

Monitoring and Debugging Network Calls

Using URLSessionDelegate for Metrics

Implement urlSession(_:task:didFinishCollecting:) to receive URLSessionTaskMetrics. This provides detailed timing information (DNS lookup, TLS handshake, request/response time) invaluable for performance tuning.

External Tools

Use Charles Proxy, Proxyman, or Wireshark during development to inspect raw HTTP traffic. For production, integrate a logging service like Datadog or Firebase Performance to capture network latency and error rates. Always strip sensitive data before sending logs to backend services.

For a deeper dive into network debugging, refer to the article “Debugging Network Requests in iOS Without Charles” on NSHipster.

Conclusion

Optimizing network calls with URLSession is not a one‑size‑fits‑all exercise. It requires thoughtful configuration, caching strategies, concurrency management, and robust error handling. By leveraging modern Swift concurrency, background sessions, and careful performance monitoring, developers can build iOS apps that feel snappy even under challenging network conditions. Start by auditing your current URLSession setup – chances are a few adjustments in configuration and caching will yield immediate improvements in user satisfaction and battery life.

Remember to test under real‑world network conditions (slow 3G, airplane mode, weak Wi‑Fi) and iterate on your optimization strategies. The tools and techniques outlined here provide a solid foundation for mastering network calls in iOS.