commerce process on macOS

Last updated: 2026-07-31

What it is

commerce is a built-in macOS background service from Apple’s private CommerceKit framework. It runs for each logged-in user rather than as a single system-wide daemon. On the locally examined macOS installation, both its code-signing identifier and its launchd service label are com.apple.commerce. Its executable is stored at /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Resources/commerce.

The service supports system clients that need to make store requests or work with Apple media-purchase accounts. Evidence in the local executable also connects it with storefront information, purchase-transaction queues, and authentication. In this context, a storefront describes the store region associated with an account and its available catalog.

These findings establish that commerce is part of Apple’s purchasing and store infrastructure. They do not establish every task the process performs. Apple publishes no dedicated commerce documentation or manual page, and CommerceKit is private. Its exact responsibilities may also vary between macOS releases.

Why it talks to the network

The local binary contains direct evidence of capabilities for retrieving store configuration, processing account and storefront information, starting purchase requests, checking a server-side purchase queue, and completing authentication. Those activities require communication with Apple’s store infrastructure, so network access from commerce is consistent with its verified role.

Possible triggers include buying something through the App Store or another Apple media store, performing or restoring a StoreKit transaction, changing an account or regional storefront, and refreshing a receipt through older StoreKit APIs. These are plausible triggers based on the verified capabilities around the process. Apple’s StoreKit documentation does not say that commerce executes every request in every one of those workflows, so they should not be treated as a complete or guaranteed trigger list.

The relevant destination categories include Apple Media Services and the configuration, authentication, and transaction systems used by the App Store or iTunes Store. A configuration address for the test environment, sandbox.itunes.apple.com, can be verified inside the local executable. A complete list of production hostnames has not been verified, and observed connections should not be assigned to a particular function merely from their timing.

How much traffic is normal

Apple has not published a normal traffic range, request frequency, or per-process baseline for commerce. There is therefore no defensible number of kilobytes or megabytes that can be presented as a universal threshold. A total that looks unusual on one Mac may correspond to account activity, transaction recovery, repeated authentication, or another store operation on a different Mac.

Its verified duties primarily concern configuration, accounts, authentication, and transaction metadata. From that role, an individual request would generally be expected to be much smaller than a complete application package or a piece of media. That is an inference about the kind of data involved, not a measured traffic limit.

There is no reliable evidence for the normal request rate, possible short bursts, or whether commerce directly carries larger downloads in some macOS versions. Apple keeps the division of work among related App Store services private. Traffic volume alone therefore cannot show exactly what the process was doing or prove that it downloaded an app.

Can you turn it off

The practical recommendation is to keep commerce available. This does not mean it is required for the basic operation of macOS. It means that Apple offers no supported way to disable it and that process-level blocking may damage purchasing features without providing a reliable system-wide store-off switch.

Apple does not provide a System Settings path or any other documented switch for turning off commerce. Force-unloading it, deleting it, or blocking it for long periods may cause store authentication, purchases, restored transactions, StoreKit state synchronization, or receipt refreshes to fail. If the process is merely terminated, launchd can start it again when a client next requests its Mach service.

Signing out of Media & Purchases changes account availability, but it is not a master switch for the process. Disabling automatic App Store updates only controls automatic updates. It does not disable the purchasing, authentication, StoreKit, and other store requests that may use this service.

What people get wrong

• “commerce is malware or a cryptocurrency miner.” The instance at the verified system path, signed and identified as com.apple.commerce, is supplied by Apple with macOS. A same-named executable found somewhere else is not covered by that conclusion and should be checked independently.

• “Disabling commerce is a harmless macOS optimization.” It provides system services related to purchases and store transactions. Apple supplies no supported disabling method, and interference can break those functions.

• “All commerce traffic consists of app installers or media downloads.” That has not been established. The directly verified capabilities mainly involve store configuration, accounts, authentication, purchase requests, and transactions. How Apple divides large-file delivery among App Store components remains private.

• “commerce contacts the network every time an app opens to validate its license.” This overstates the evidence. StoreKit, local application code, or a developer-controlled server can validate receipts or transactions. Apple has not shown that every launch goes through commerce.

• “commerce itself performs server-side verifyReceipt validation.” Apple’s guidance places calls to the relevant server service on a developer’s secure server, while modern StoreKit can validate Apple-signed transactions. The exact involvement of the local commerce process in those validation paths has not been verified.

• “com.apple.commerc is another official bundle identifier.” The verified identifier is com.apple.commerce. The shorter form is more likely a truncated name produced by a collection or display layer, although the exact source of that truncation still requires manual verification.

• “Turning off automatic App Store updates stops commerce.” Automatic updates are only one store setting. Turning them off does not shut down the background services used for purchases, authentication, StoreKit operations, or other store requests.

Seeing what it actually used

When the question is about one particular Mac, the next step is to measure rather than infer from a generic threshold. Use Bytetally’s per-process statistics to observe how much network traffic commerce actually records during the period in question. Compare that period with purchases, restored transactions, account changes, or other store activity you initiated, while remembering that timing alone does not prove the purpose of a connection.

Related processes

Common questions