What is appstored on Mac, and why is it using the network?

Last updated: 2026-07-31

What it is

appstored is Apple’s system-level support daemon for the App Store. It is launched by launchd under the dedicated _appstore account, and its Apple identifier is com.apple.appstored. The system executable is located at /System/Library/PrivateFrameworks/AppStoreDaemon.framework/Support/appstored.

Its job is to coordinate App Store operations behind the scenes. Those operations include discovering available updates, installing apps, restoring apps, and supporting re-downloads. appstored is not the App Store window or the visible application that you interact with.

It is also not safe to assume that appstored personally performs every step of every App Store transaction. Apple has several related processes, including appstoreagent, storedownloadd, and storeassetd. Apple does not publicly document the complete division of work among them. Describing appstored as supporting or coordinating App Store activity is therefore more accurate than attributing every download, validation request, or connection to it alone.

Why it talks to the network

Several ordinary App Store events can lead to network activity around appstored. macOS may be checking whether installed apps have updates. It may be downloading or installing an update, processing a purchase or re-download requested by the user, automatically downloading an app purchased on another device, or retrieving optional in-app content.

The services involved can include Apple’s App Store metadata and account systems. Content may come from hosts under *.apps.apple.com, *.itunes.apple.com, and *.mzstatic.com. Additional content can also use third-party CDNs. If a macOS Content Cache is available on the local network, some content may come from that cache instead of a remote host.

These categories describe the wider App Store subsystem, not a verified endpoint list for appstored alone. Apple does not publish a definitive per-process endpoint map. Consequently, the owner of every individual connection or payload cannot be established from the process name and destination category alone.

How much traffic is normal

There is no reliable fixed MB figure for normal appstored traffic. Apple does not publish a process-specific range, so a precise daily or hourly allowance would be unsupported.

When the App Store is only checking for updates, the traffic should normally be intermittent metadata traffic and small compared with downloading an application. During an installation, update, re-download, or additional-content download, the amount instead follows the size of the requested app or asset. Such a transfer can temporarily account for a major share of the Mac’s network use.

Context matters more than a universal threshold. A short burst during a known app download has a straightforward explanation. The same volume at an unexpected time may deserve investigation, but volume alone does not reveal which App Store task generated it or which related process owned each connection.

Can you turn it off

Apple provides no supported System Settings switch that disables appstored itself. Blocking it, deleting its launch definition, or repeatedly forcing it to stop can break or stall app installations, updates, re-downloads, and related validation work. Because launchd can start it again when it is needed, killing it is not a reliable way to control App Store traffic either.

For a narrower, supported control, open the App Store and go to App Store > Settings > Automatic Updates. Turning Automatic Updates off means app updates must be started manually. It does not disable appstored, and it does not prevent traffic caused by manual App Store actions or by other download options that remain enabled.

Deprioritizing a bulk background transfer can be reasonable when bandwidth is needed elsewhere. That should not be treated as permission to block App Store service hosts or disable the daemon. If an installation or update was started by the user, throttling it will slow the requested operation and should not happen without making that consequence clear.

What people get wrong

1. “appstored is malware because it runs without an App Store window.” The executable at Apple’s protected system path with identifier com.apple.appstored is an Apple system daemon. A different executable using the same name somewhere else should be investigated on its own merits.

2. “It only checks for updates, so every byte it transfers is an automatic update.” The App Store subsystem also supports manual installs, purchases, re-downloads, automatic downloads from purchases on another device, and optional content. Apple has not fully documented which worker owns each connection.

3. “It handles every macOS operating-system update.” Apple documents appstored as an App Store support daemon. It is not documented as the sole engine for macOS software updates.

4. “Turning off Automatic Updates disables appstored completely.” That setting stops automatic App Store app updates. The daemon remains available for manual updates and other App Store operations.

5. “Deleting its launch daemon or repeatedly killing it is a harmless optimization.” This is unsupported and can interfere with normal App Store behavior. launchd may start appstored again on demand.

6. “High appstored traffic must be telemetry.” App and additional-content downloads provide a normal explanation for high-volume traffic. Calling a particular transfer telemetry requires evidence about that specific connection; the process name and byte count are not enough.

Seeing what it actually used

The next step is to measure appstored over the exact period that concerns you and compare it with any App Store action happening at the same time. Bytetally’s per-process statistics can show how much network traffic was attributed to appstored during that period. That measurement establishes the amount used, but identifying a payload as telemetry or assigning every connection to a specific App Store worker still requires connection-level evidence.

Related processes

Common questions