According to the legacy docs, Apple provides a default NSURLCache implementation for all applications running on iOS 5 and above.
Applications that do not have special caching requirements or constraints should find the default shared cache instance acceptable. An application with more specific needs can create a custom NSURLCache object and set it as the shared cache instance using
setSharedURLCache:. The application should do so before any calls to this method.
The new API reference, however, does not specify this information on the current page for URLCache.shared.
My application has a requirement to not cache any network requests or responses. For applications targeting iOS 9 and above, does Apple still provide a shared NSURLCache? If so, how would I completely disable it, ignore it, or set the capacity to 0 for any NSURLSession requests?
Nothing changed in that area other than Apple's new developer docs site managing to take usability, searchability, and scannability to an all-time low. But I'm sure the information you seek is on one of the fifty or so subpages linked off the one you're looking at.
It was bad enough when it affected only their WWDC site. Now, the bad design seems to have metastasized. Sorry that it impacted your ability to write software as much as it has mine.
One word: rollback. Just saying.
But to answer your original question, yes, there's still a shared cache. They can't remove it without adversely affecting compatibility, realistically.
Note, however, that NSURLSession requests don't necessarily use the same cache, depending on how the session is configured. And the easiest way to avoid caching is still to use NSURLSession and explicitly nil out the session cache in the configuration. Of course, that only affects requests that you make yourself through that session (and not, for example, through a web view).