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

Last updated: 2026-07-31

What it is

sharingd is a system background process supplied by Apple with macOS. It runs from /usr/libexec/sharingd, uses the code identifier com.apple.sharingd, and is kept running for the logged-in user by launchd. It is not a third-party sharing application, even though its unfamiliar name can make it look suspicious in a process or network monitor.

Verified local LaunchAgent metadata registers services for AirDrop, Handoff advertising and scanning, Share menu recipients, and transfer observation. Apple also documents that Universal Clipboard is built on Handoff, so clipboard activity between nearby devices belongs to the same functional area.

That evidence does not establish a complete list of everything sharingd does. Apple has not published its full responsibilities, and the precise boundary between sharingd and other Continuity features remains unverified. It is therefore reasonable to associate the process with the services explicitly registered in the system metadata, but not to assign every Continuity action to it.

Why it talks to the network

When AirDrop receiving is available, or when a Share menu looks for nearby recipients, sharingd participates in discovering nearby Apple devices. The documented AirDrop mechanism begins with Bluetooth Low Energy discovery. The devices then negotiate an encrypted, peer-to-peer Wi-Fi connection for the transfer. Apple’s security documentation says the standard nearby transfer is protected with TLS.

Handoff creates another source of activity. When Handoff is enabled, nearby devices signed in to the same Apple Account exchange activity advertisements. Apple says APNs may be used during initial pairing or for some messages, while larger Handoff content can move over peer-to-peer Wi-Fi. Universal Clipboard relies on Handoff, so copying content on one device and pasting it on another can trigger related communication.

The other endpoint is therefore not always “one of your own devices,” and it is not always strictly local. AirDrop can communicate with another person’s nearby Apple device. Apple iCloud or APNs infrastructure may also be involved in authentication, pairing, or forwarding messages.

Apple’s current documentation further states that an AirDrop transfer which has already begun may continue over the internet after the devices leave Bluetooth or Wi-Fi range. This does not show that every AirDrop file is first uploaded to an Apple cloud service. The exact relay design for internet continuation is not fully disclosed in the researched material, and Apple has not published how the resulting connections are divided among sharingd, apsd, and the networking stack.

How much traffic is normal

Apple does not publish a reliable normal byte range for sharingd. A fixed threshold in kilobytes or megabytes would therefore be invented rather than evidence-based.

The plausible scale follows the action taking place. Nearby discovery, availability updates, and Handoff activity advertisements may involve relatively small amounts of control data. An AirDrop transfer can produce traffic comparable to the file being sent, and a large Handoff item can likewise be substantial. Universal Clipboard traffic generally depends on the size of what was copied.

Even those comparisons do not create a precise per-process allowance. System accounting may assign some of the work to sharingd, apsd, or other networking components, and the exact split is not public. A large number beside sharingd is therefore not proof of a leak, while a small number does not by itself identify which feature was active.

Can you turn it off

Apple does not provide a System Settings switch or path for turning off sharingd itself. Its LaunchAgent is configured with KeepAlive, so simply ending the process will normally cause launchd to start it again.

Unofficially deleting, blocking, or disabling the process may disrupt AirDrop, Handoff, Universal Clipboard, nearby recipients in the Share menu, transfer observation, and other Continuity behavior that Apple has not fully documented. There is no verified basis for claiming that doing so will safely accelerate the Mac or save a large, predictable amount of traffic.

Apple does provide controls for individual features. AirDrop receiving can be set to “No One” under System Settings > General > AirDrop & Continuity; some macOS installations label that area “AirDrop & Handoff.” Turning off “Allow Handoff between this Mac and your iCloud devices” on the same page also disables Handoff and Universal Clipboard. These settings limit particular features; they are not a master switch for sharingd.

What people get wrong

• “sharingd is malware or a suspicious third-party sharing tool.” It is an Apple system component. Local system metadata places the executable in /usr/libexec, identifies it as com.apple.sharingd, and shows it being started by an Apple LaunchAgent under /System/Library.

• “sharingd exists only for AirDrop.” That description is incomplete. Its registered services also cover Handoff advertising and scanning, nearby Share menu recipients, and transfer observation. Universal Clipboard is relevant because Apple documents it as a Handoff feature.

• “It talks only to my own nearby devices and never uses the internet.” AirDrop can connect to another person’s nearby Apple device. iCloud and APNs may take part in authentication, Handoff pairing, or message forwarding, and Apple says an AirDrop transfer already in progress may continue over the internet after the devices leave local wireless range.

• “AirDrop uploads every file to Apple’s cloud before delivery.” The researched evidence does not support that claim. Apple describes the standard nearby path as a TLS-encrypted, peer-to-peer Wi-Fi transfer. The architecture used when an existing transfer continues over the internet was not fully disclosed in the reviewed material.

• “Killing or deleting sharingd is a safe way to speed up the Mac and save lots of data.” There is no reliable evidence for either benefit. launchd normally restarts the process, while forcing it off may damage several sharing and Continuity features.

• “High sharingd traffic proves macOS is leaking files in the background.” A byte count alone cannot establish that. An intentional AirDrop transfer or a large Handoff item may naturally generate traffic comparable to the content involved. The useful evidence is what sharing action occurred, which endpoint was contacted, which network path was used, and how the system attributed the traffic.

Seeing what it actually used

Start by matching the time of the traffic with AirDrop, Handoff, Universal Clipboard, or Share menu activity, then inspect the destination and network path instead of judging the process name alone. Bytetally’s per-process history can show how much traffic was attributed to sharingd and when it occurred, but it cannot resolve Apple’s unpublished division of work among system components. Compare those observations with what you were doing before deciding whether the activity needs further investigation.

Related processes

Common questions