Asynchronous image downloading and caching.
In-Memory Cache: NSCache
Apple defines NSCache like this:
An NSCache object is a mutable collection that stores key-value pairs, similar to an NSDictionary object. The NSCache class provides a programmatic interface to adding and removing objects and setting eviction policies based on the total cost and number of objects in the cache.
NSCache holds the item in memory and is used for optimal performance. But it takes up memory (RAM) and you really should make sure that if you use NSCache that you respond to memory warnings and purge the NSCache in those cases. And when the app terminates, the NSCache is lost.
https://medium.com/journey-of-one-thousand-apps/caching-images-in-swift-e909a8e5db17
Manage Duplicate Downloads
Sometimes application logic can end up attempting to download an image more than once before the initial download request is complete. Most often, this results in the image being downloaded more than once. AlamofireImage handles this case elegantly by merging the duplicate downloads. The image will only be downloaded once, yet both completion handlers will be called.
Disk Cache
Using persistent storage cache (generally the Caches folder) is used for a different purpose, saving you from needing to re-retrieve the asset via some network request, but not holding the resource in memory. This makes it a great cache mechanism across sessions of running the app or in situations where you may have encountered memory pressure, purged the NSCache, but didn't want to re-retrieve the asset from the network.
Two-Tier Cache
Note, we'll often use a two-tier cache mechanism. Cache the resource to both NSCache and the Caches folder. Then, when you go to retrieve a resource, first check NSCache (really fast), if not there, check persistent storage, and if not there, re-retrieve the asset from the network.
URL Caching
The URL Loading System caches responses both in memory and on disk, improving performance and reducing network traffic.
Set a Cache Policy for URL Requests
Each URLRequest instance contains a URLRequest.CachePolicy object to indicate if and how caching should be performed. You can change this policy to control caching for the request.
For convenience, URLSessionConfiguration has a property called requestCachePolicy; all requests created from sessions that use this configuration inherit their cache policy from the configuration.
useProtocolCachePolicy is the default value for a URLRequest object. usePrococolCachePolicy caches HTTPS responses to disk, which may be undesirable for securing user data. You can change this behavior by manually handling caching behavior, as described in Manage Caching Programmatically.
https://developer.apple.com/documentation/foundation/url_loading_system/accessing_cached_data
HTTP Caching
When a client makes a request to a server, the HTTP response includes a set of HTTP headers, including some which serve as directives for how that response should be cached:
Cache-Control - This header must be present in the response from the server to enable HTTP caching by a client. The value of this header may include information like its max-age (how long to cache a response), and whether the response may be cached with public or private access, or no-cache (preventing the cache from using the response for a subsequent request, without revalidation).
In addition to Cache-Control, a server may send additional headers that can be used to conditionally request information as needed:
Last-Modified - The value of this header corresponds to the date and time when the requested resource was last changed. For example, if a client requests a timeline of recent photos, /photos/timeline, the Last-Modified value could be set to when the most recent photo was taken.
Etag - An abbreviation for “entity tag”, this is an identifier that represents the contents requested resource. In practice, an Etag header value could be something like the MD5 digest of the resource properties. This is particularly useful for dynamically-generated resources that may not have an obvious Last-Modified value.
Request headers Once a client receives a response with any of these cache headers, their values can be sent on subsequent requests to conditionally ask the server for information only if the resource has changed:
If-Modified-Since - This request header corresponds to the Last-Modified response header. Set the value of this to the Last-Modified value received from the last request to the same endpoint. If the resource has not been updated since the last request, the server will send a 304 (not modified) status code response.
If-None-Match - This request header corresponds to the Etag response header. Use the Etag value received previously for the last request to that endpoint. If the value on the server is the same as requested by the client, then the resource has not been changed, and a 304 (not modified) status code will be returned.
curl -I www.google.com show all the headers