One of the many fine details in macOS is its built-in support for a content caching service, both as server and client. This can be used for local distribution of macOS and other system updates, App Store updates, Apple media content such as Music and movie purchases, and iCloud content.

This appears to have originated as one of the new services added to Mac OS X Server 10.4 Tiger in April 2005, initially confined to a Software Update server. Apple’s online services were growing rapidly at the time, with the iTunes Store opening in 2003, and the first of its App Stores for iOS launching in 2008. Those were followed by the iCloud service in 2011. To cater for those, Apple added a separate Content Caching server by OS X Server 2 in 2012.

This shows the Software Update service in OS X Server 2 in 2012, with a list of some of the updates it had in its cache at the time.

At that time, a client Mac’s Software Update pane in System Preferences had to be pointed at the local server for that to be used instead of Apple’s. However, that didn’t work with App Store caching, for which the /Library/Preferences/com.apple.SoftwareUpdate.plist file had to be edited manually on each client to add a new property specifying the IP address of the local server.

macOS Server 5 in 2015 extended this further.

Features of the Software Update server then included the ability to limit the server’s bandwidth in its link back to Apple’s servers, and to control local network bandwidth used to transfer updates from the server to clients.

Amazingly, its original documentation is still available online here, and instructions for setting up clients remain here.

The Caching service worked with all content and apps provided by the Mac App and iTunes Stores, which of course included OS X updates, and is explained here. By this time, Macs and iOS devices connected to the local network would automatically find a server when it was running; there was minimal configuration for the server, and none for the clients.

When macOS 10.13 High Sierra was released in 2017, that brought update and content caching services to client Macs, and no longer required macOS Server, which was already in its terminal decline. These were configured in a new Content Caching feature added to the Sharing pane in System Preferences.

In essence, you designated one or more Macs as ‘parents’, to serve their cached content to ‘children’, which can themselves host caching services, to allow tiered setups. Initially, parents also needed to share their internet connection, required a minimum of iOS 10.3 for iOS devices, required a wired Ethernet connection to your router, and couldn’t sleep, so had to be run on mains power.

Although the content caching service has become quite widely used since, it’s never been as popular as it deserves. It remains remarkably simple to set up, as seen in these screenshots from 2020.

Clicking on the Options button let you set the cache location and its size.

Tabs were made available if you held the Option key before clicking the Options button, which then became Advanced Options. That let you set up clients, as well as other servers functioning as peers or parents, on more extensive networks.

These remain essentially the same today in Tahoe.

When Apple changed macOS updates in Big Sur, life became more complicated. When updating Apple silicon Macs, the first GB of macOS updates had to be downloaded direct from Apple’s servers, and it was only after that the remainder of the update could be obtained from a local caching server.

Apple has further extended the types of content that can be cached locally, to include

• macOS updates normally obtained through Software Update or the command tool softwareupdate;
• internet Recovery images from macOS 10.13.5 onwards when obtained in Recovery mode;
• apps and their updates supplied through the Mac and iOS App Stores;
• GarageBand downloadable content;
• iCloud documents and data, including Photos libraries;
• Apple Books;
• downloadable components for Xcode.

Most recently Rosetta 2, screen savers, wallpaper and AI models have been added to the list. Apple’s reference document is here.

Advanced server configurations are catered for by the command tool AssetCacheManagerUtil which can also provide performance information, and there are two additional tools available, AssetCacheLocatorUtil and AssetCacheTetheratorUtil. On the server, performance information is most readily accessed in Activity Monitor’s Cache view, which provides summary statistics for the local cache.

This includes the total size of data served for the last hour, 24 hours, 7 days, and 30 days. To view those graphically, the time period for the charts at the foot can be changed by using it as a popup menu.

These show what happened on my content caching server during the macOS 11.4 update in 2021, for which almost 30 GB still had to be downloaded from Apple’s servers, while just over 20 GB was served from its cache.

Over the last 20 years or so, Software Update and Content Caching services have been remarkably reliable, but in June 2022 there was a period during which updates to XProtect and XProtect Remediator failed to install correctly when attempted through a content caching server. Apple never explained what the cause of that was, but it was eventually fixed and hasn’t recurred since.

Then, out of the blue, iOS and iPadOS 26 introduced a new feature to identify and test a connected caching server.

To access this, in Settings > Wi-Fi tap the ⓘ button on your current active network, scroll to the bottom and tap Content Caches. Tap the active cache to see full details, together with a download test. Don’t bother looking for an equivalent feature in macOS 26 Tahoe, though, as it isn’t available yet. How odd.