What is AssetCacheLocatorService on Mac?

Last updated: 2026-07-31

What it is

AssetCacheLocatorService is an XPC service supplied by Apple as part of macOS. Its job is to find content caches that can be used by system daemons and by the current user, refresh previously saved location results, and check whether candidate caches are reachable. The executable belongs to com.apple.AssetCacheLocatorService and is installed inside Apple’s private AssetCacheServices framework.

AssetCacheLocatorService is not the content cache itself. The separate AssetCache service stores and serves cached files. AssetCacheLocatorService handles the discovery side: it maintains possible cache locations, checks them, and helps supported Apple clients select a suitable cache. When one is available, supported Apple software updates, apps, and some iCloud content can be retrieved from it.

A “local” or “nearby” content cache usually means a cache on a nearby network. It does not mean that every step of locating that cache remains inside the local network. AssetCacheLocatorService may use Apple’s internet-based locator infrastructure as part of the process.

Why it talks to the network

Network activity can begin when an Apple content client needs to find a cache, when a saved locator result needs refreshing, or when the Mac’s network configuration changes. An administrator can also trigger locator activity by running diagnostics with AssetCacheLocatorUtil.

The verified connection targets fall into several categories. AssetCacheLocatorService can contact Apple’s lcdn-locator.apple.com service over HTTPS on TCP port 443. It can perform DNS lookups used by custom public-address-range or favored-server configurations. It can also communicate with candidate content caches on localhost or elsewhere on the network and probe whether those candidates are reachable.

Apple additionally requires macOS content-cache clients to reach serverstatus.apple.com over TCP 443 so that the client’s public IP address can be determined. Public documentation does not establish that AssetCacheLocatorService itself always makes that connection, so a connection to that host should not automatically be attributed to this executable without process-level evidence.

These requests support cache discovery and validation. They are not, by themselves, evidence that AssetCacheLocatorService is downloading an entire app, system update, or iCloud item.

How much traffic is normal

There is no reliable published byte count, megabyte range, or fixed traffic baseline for AssetCacheLocatorService. Apple has not documented its normal per-process data usage, refresh frequency, or complete private implementation. A precise allowance such as “a few megabytes per day” would therefore be unsupported.

Based only on its verified responsibilities, ordinary activity should mainly consist of intermittent DNS requests, HTTPS locator queries, and reachability checks against candidate caches. That control traffic would normally be much smaller than downloading a complete app or macOS update. The exact amount can still vary with cache lookups, result refreshes, network changes, administrator diagnostics, and the number of candidates being checked.

The executable also contains private methods associated with importing content into a local cache. When those methods are called, and whether any related data is recorded under this process name, have not been verified. An unexpectedly large total should therefore be investigated with process-level measurements rather than compared with an invented universal threshold.

Can you turn it off

Apple does not provide a System Settings switch that disables the AssetCacheLocatorService client locator. The path Apple menu > System Settings > General > Sharing > Content Caching controls whether this Mac provides cached content to other devices. It does not turn off the Mac’s ability to act as a client and discover caches offered elsewhere.

Forcibly blocking or disabling AssetCacheLocatorService may prevent the Mac from finding or validating an available content cache. Supported downloads may then fall back to the internet, increasing external bandwidth use and slowing repeated downloads across multiple devices. The service’s ordinary locator traffic is generally control traffic, while the cache it discovers may avoid much larger duplicate downloads.

This does not establish that the process can never malfunction or use an unexpected amount of data. It means that disabling it is not equivalent to disabling an optional download feature, and Apple supplies no supported client-side off switch.

What people get wrong

• “AssetCacheLocatorService only creates LAN traffic.” That is incorrect. Apple’s network documentation requires content-cache clients to reach lcdn-locator.apple.com over TCP 443, and the system executable contains the corresponding HTTPS URL. Candidate caches may be nearby, but the locator process is not necessarily LAN-only.

• “Turning off Content Caching in System Settings stops AssetCacheLocatorService.” That setting determines whether the Mac serves cached content to other devices. Apple devices can still operate as clients and automatically look for caches available on their network.

• “AssetCacheLocatorService downloads updates or stores the cached files.” Apple’s manual page describes it as the cache locator. AssetCache is the service that actually provides content caching. Seeing network activity under the locator’s name does not prove that it transferred the full update or app.

• “Blocking it will speed up the Mac or clearly reduce data use.” Locator requests are control traffic. Blocking discovery can remove the opportunity to reuse a nearby cache, causing supported content to be downloaded in full from the internet instead. That can increase, rather than reduce, external traffic.

• “A connection to lcdn-locator.apple.com means malware or advertising tracking.” There is no basis for that conclusion. Apple documents the host as a content-cache locator endpoint, and AssetCacheLocatorService is a platform component included with macOS. Apple has not published every request field or the server-side retention policy, however, so it would also be unsupported to claim that all metadata exchanged by the service has been completely audited.

Seeing what it actually used

If the concern is an unusual transfer rather than the service’s identity, the next step is to measure AssetCacheLocatorService by process over the period in question. Bytetally’s per-process statistics can show its observed upload and download totals so they can be compared with the timing of network changes, updates, or cache diagnostics. That evidence is more useful than applying an unsupported universal megabyte threshold.

Related processes

Common questions