Understanding different cache policies when working with URLRequest in Swift

When in comes to server communication in iOS, the system provides different caching strategies to improve performance and reduce network traffic.

By choosing a cache policy, we can decide whether the caching should depend on expiration dates or disabled entirely or whether the server should be contacted to determine if the content has changed since the last request.

Let's jump in and explore available URLRequest cache policies and their consequences.

Architecture & Design Patterns for iOS

This book is a practical guide to essential architectural principles and design patterns for iOS development. It covers strategies for building maintainable apps with Swift and SwiftUI, including dependency injection, navigation, common patterns, and modularization.

LEARN MORE

Setting a cache policy for URL requests

When creating a URLRequest, we can use its cachePolicy property to specify which caching should be performed, for example:

let urlRequest = URLRequest(url: url, cachePolicy: .reloadIgnoringLocalCacheData)

Alternatively, we can set the desired caching policy when configuring a URLSession. All requests created from this session inherit its cache policy.

let configuration = URLSessionConfiguration.default
configuration.requestCachePolicy = .returnCacheDataElseLoad

let urlSession = URLSession(configuration: configuration)

The following caching policies are available:

• .useProtocolCachePolicy
• .reloadIgnoringLocalCacheData
• .reloadIgnoringLocalAndRemoteCacheData
• .returnCacheDataElseLoad
• .returnCacheDataDontLoad
• .reloadRevalidatingCacheData

Let's go through each policy and see how the cache is being managed.

.useProtocolCachePolicy

The .useProtocolCachePolicy value is the default cache policy. It uses the caching logic defined in the protocol implementation.

When working with HTTP or HTTPS, the caching capabilities are built into the protocol so the server is able to communicate with the client on how the content should be cached.

For example, the server might send the following cache control headers:

Last-Modified: Mon, 08 Dec 2014 19:23:51 GMT
ETag: "adg2jl4kfmm5"
Cache-Control: max-age=533280
Expires: Sun, 03 May 2024 11:02:37 GMT

We don't need to dive deeper into what each header means, since the caching policy will do all the work for us. So depending on the values the server sends, the caching policy will basically perform the following behaviour:

• In case no cached response is available, the system fetches the data from the URL.
• In case a cached response is available, not expired and doesn't always require revalidation, the system returns the cached response.
• In case a cached response is available, but expired or requires revalidation, a HEAD request is send to the server to check if the resource changed. If it's changed, the system fetches the data from the URL. Otherwise, it returns the cached response.

.reloadIgnoringLocalCacheData

The .reloadIgnoringLocalCacheData policy is self-explanatory, it simply fully ignores local cache data always sending the request to the server.

.reloadIgnoringLocalAndRemoteCacheData

The .reloadIgnoringLocalAndRemoteCacheData also fully ignores local cache data. Additionally, it instructs proxies and other intermediates to ignore their caches so far as the protocol allows.

.returnCacheDataElseLoad

The .returnCacheDataElseLoad policy always uses cached data if available ignoring its age or expiration date. It sends the request to the server only if there is no cached data.

.returnCacheDataDontLoad

The .returnCacheDataDontLoad policy always uses cached data. If no cached data is available, it returns an error. So a request is never send to the server.

.reloadRevalidatingCacheData

The .reloadRevalidatingCacheData policy uses cached data if it can be validated by the server. Otherwise, the request is send to the server.