URLCache returnCacheDataElseLoad heuristic freshness when servers omit cache headers

Background

URLCache's .returnCacheDataElseLoad policy serves a cached response if one exists, even when the entry is stale by HTTP freshness rules. When a response lacks explicit freshness headers such as Expires or Cache-Control: max-age, the cache applies an undocumented heuristic—approximately 10% of the time elapsed since the Date header—to decide whether the entry is still fresh enough to serve without revalidation.

Uncertainty

Apple's API reference does not document this heuristic, and its behavior has not been confirmed in recent OS releases. The cache may have shifted to a different stale-while-revalidate approach, or the 10% rule may persist unchanged. Applications that depend on timely data (for example, financial feeds or live scores) cannot rely on the cache to self-invalidate without explicit server guidance.

Goal

Determine whether the heuristic remains consistent across supported iOS and macOS versions, and identify a reliable configuration or validation strategy that prevents stale data from being served when the server provides no freshness directives.

• Does the 10% age-based heuristic still govern freshness in current OS releases, or has it been replaced?
• Can a custom URLCache subclass or NSURLProtocol intercept and enforce stricter freshness checks without disabling caching entirely?
• What is the minimal set of response headers a server must include to make .returnCacheDataElseLoad behave predictably?