URLCache selective purge by age or URL pattern for mutable responses

Answer

When a server returns a mutable response without an ETag or a short max‑age, the cache cannot rely on a server‑provided validator to decide freshness. The only reliable boundary is the response’s timestamp (the Date header) together with any freshness header the server may send, such as Last‑Modified or Expires. If none of those are present, the application must treat the cached object as valid only until the elapsed time exceeds a reasonable limit, or it must force a fresh fetch by using reloadIgnoringLocalCacheData for critical reads.

Confirmed facts

URLCache does not compute HTTP freshness itself; it only respects the CachePolicy and the response’s timestamps. The public API offers removeCachedResponse(for:) and removeAllCachedResponses(), but no predicate for age, URL pattern, session, or tag, and memory or disk capacity limits are storage constraints, not freshness rules. Selective eviction therefore requires a custom subclass that overrides the removal logic while preserving the cache’s capacity management.

Steps to verify

1. Check the response’s Date header and compare it to the current time.
2. If the server provides any freshness header (Last‑Modified, Expires, Cache‑Control), use that to decide staleness.
3. If no header is present, decide based on elapsed time or request a new validator from the server.
4. To purge by age or URL pattern, subclass URLCache and override removeCachedResponse(for:) to inspect the URL and age, then call super.removeCachedResponse.
5. Test the subclass on iOS 13+ devices to confirm stability across supported OS versions.

Please let me know if the server supplies any freshness header (e.g., Last‑Modified, Expires, Cache‑Control) that can be used to determine staleness.