Understanding different cache policies when working with URLRequest in Swift
Learn how to manage cache when sending HTTP requests in your iOS applications.
31 Oct 2022 · 4 min read
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.

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.defaultconfiguration.requestCachePolicy = .returnCacheDataElseLoadlet 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 GMTETag: "adg2jl4kfmm5"Cache-Control: max-age=533280Expires: 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.

Newsletter
Like to support my work?
Say hi
Related tags
Articles with related topics
Latest articles and tips