What Is searchpartyd on Mac? Find My Off, Still Listening

searchpartyd is the Find My network daemon on a Mac. It handles the keys and Bluetooth sightings behind offline finding: the feature that lets a lost AirTag or a sleeping Mac be located by other Apple devices nearby. On my Mac mini, Find My Mac is off and no Apple Account is signed in, and searchpartyd is still running. In the 70 minutes of detailed log I could read, it took in 1,574 batches of Bluetooth advertisements and logged the same line for each one: Ignoring advertisements while finder is off.

So the short answer to "what is searchpartyd" is Find My. The more useful answer is what it does when Find My is off, because that is the case where people go looking for it in Activity Monitor and wonder why it is there.

The rig is a headless Mac16,10 (M4) on macOS 26.4.1 (25E253), up 21 days, measured on 2026-10-19 as an admin user without sudo.

Two processes, one daemon and one agent

$ ps -axo pid,user,time,etime,command | grep [s]earchparty
  826 root      13:38.56 21-09:12:45 /usr/libexec/searchpartyd
 1007 sg-mini    0:40.02 21-09:12:44 /usr/libexec/searchpartyuseragent

Both come from launchd. If the difference between the two folders is new to you, LaunchAgent vs LaunchDaemon explains it.

Job	Runs as	What its plist registers
/System/Library/LaunchDaemons/com.apple.icloud.searchpartyd.plist	root	12 Mach services, including BeaconScanningSession, ObservationStoreService, BeaconKeyService, advertisementcache and finderstatemanager
/System/Library/LaunchAgents/com.apple.icloud.searchpartyuseragent.plist	your user	10 notification triggers, including Find My state changes, Family changes and location authorization

The daemon binary is 47,981,584 bytes and universal (x86_64 and arm64e). The service names describe the job: scan for beacons, store observations, manage keys. "Search party" is Apple's internal name for the offline finding network.

Apple's Find My security guide describes the design. A device with offline finding on "can detect the presence of another missing offline device using Bluetooth," encrypts its own location to that device's public key, and uploads it. Apple says "Approximately every 15 minutes, the public key is replaced by a new one." That 15-minute number shows up again in my log below.

Find My is off here, and both processes are still running

I checked the Find My state three ways before trusting the log:

$ defaults read com.apple.icloud.searchpartyuseragent | grep -i state
    "FMIPStateManager.fmipState" = 0;
    "sharesremovalservice::findmyappstate" = 1;
    "sharesremovalservice::findmydevicestate" = 0;

$ nvram -p | grep -i fmm
$                                   # no fmm-* keys

$ launchctl print system/com.apple.icloud.searchpartyd | grep -E "runs|immediate reason|last exit"
	runs = 1
	immediate reason = ipc (mach)
	last exit code = (never exited)

Find My Mac is off, and the daemon has started exactly once in 21 days and never exited. Something keeps calling it over its Mach services, and the plist sets EnablePressuredExit, so launchd would let it quit when idle. It never gets idle enough.

This contradicts a common fix. iBoysoft's glossary page says that since searchpartyuseragent works for Find My Mac, you "can turn it off to remove the process." On this Mac, Find My Mac is off and searchpartyuseragent has been running for 21 days. Turning it off may stop the agent's work. It did not stop the agent here.

What it does with Find My off: receive, then drop

I exported every searchpartyd and searchpartyuseragent line from the unified log with /usr/bin/log show --info --debug --last 21d (the /usr/bin path matters in zsh; see the log show command). The export had 56,142 lines. All but a handful are from 2026-10-19, and the Info-level lines start at 19:50:08, so the detailed window is about 70 minutes. Inside that window, the pattern repeats the same way every time:

One chain from a live five-minute capture, trimmed:

searchpartyd  'saveBeaconPayloads:completion:': Transaction created
searchpartyd  Opened [TXN:SaveObservedAdvertisment.<UUID>]
searchpartyd  [WorkItemQueue FinderStateObserverQueue] Start processing workItem: <UUID>
searchpartyd  Ignoring advertisements while finder is off.
searchpartyd  Closed [TXN:SaveObservedAdvertisment.<UUID>]

In the same capture, bluetoothd held open Bluetooth sessions named com.apple.icloud.searchpartyd-central-826-11 and -12, where 826 is the daemon's PID. So bluetoothd is still feeding searchpartyd as a scanner, searchpartyd still opens a transaction to save what it saw, and only then checks whether this Mac is acting as a finder. It is not, so the batch goes nowhere. 1,574 of 1,574 ignore lines sit inside a SaveObservedAdvertisment transaction, and the window holds 1,576 activity records, which is close to one per batch.

Activity records reach further back than the Info lines, so they give a rough count for the whole day. If the one-to-one ratio holds outside the window (I only verified it inside), the volume looked like this:

2026-10-19 (KST)	searchpartyd activities
00:00–07:59	539 total (58 to 82 an hour)
08:00–08:59	374
09:00–19:59, per hour	3,232 to 7,207 (peak 10:00)
20:00–20:59	1,074
Total to 21:00	49,004

That is a jump of roughly 50 to 100 times between night and day. I don't know the cause. The Mac did not move and nothing about Find My changed. The likeliest explanation is more Bluetooth devices nearby during the day, but I have no way to list them from this shell, so I am not claiming it.

The 15-minute loop that publishes nothing

The agent has its own schedule. com.apple.searchpartyd.OwnDevicePublish ran 82 times between 00:33 and 20:48, with gaps of 13.9 to 16.0 minutes (median 14.95). Every run printed the same thing:

Start publishing own device beacons.
Finding unpublished payloads for 0 owned beacons and 0 shared beacons.
Got 0 payloads to publish for own devices.
No observations to publish for owned devices.

Fifteen minutes matches the key rotation period in Apple's security guide. With no account, there are no owned beacons and nothing to publish, so 82 runs did nothing. Two other lines repeat through the day: 29 failed lookups of the time daemon (com.apple.timed.xpc, then "Daemon connection invalidated"), and 5 × "This is not a me device, Safe Locations can't be refreshed."

What it costs: about 38 seconds of CPU a day

searchpartyd used 818.6 seconds of CPU in 21.4 days, about 38 seconds a day, or 0.04% of one core on average. That puts it 54th of 715 processes on this Mac. Its Bluetooth and location neighbours used more: locationd 1,625.8 seconds and bluetoothd 1,378.2. The agent used 40 seconds total.

In the five-minute live capture (21:02 to 21:07), searchpartyd handled 12 batches and its CPU time rose by 0.02 seconds. At the 10:00 peak the same five minutes would have held about 600 batches, which suggests the cost follows how busy the Bluetooth neighbourhood is rather than a timer.

For comparison on the same rig: cloudd used about 2.9 seconds a day with the same missing account, and apsd, which carries the push traffic Find My would use, delivered 46 pushes in 21 days. syspolicyd is the actual top CPU process here, at 160,480 seconds. searchpartyd is not what slows this Mac down.

When it does go wrong

Runaway searchpartyd is real, just rarer than the cleaner-app articles suggest. The longest public report I found is an Apple Developer Forums thread from August 2023: searchpartyd "keeps spinning up and taking an enormous amount of CPU and energy" through every Sonoma beta, with "No BeaconStoreActor available!" errors in Console. Replies run to August 2024 (Sonoma 14.5, an M3 MacBook Air). No Apple reply and no fix are posted.

Outside that thread the trail is thin. The Stack Exchange API returned 0 Ask Different questions with searchpartyd in the title and 2 posts that mention it in passing. Hacker News Algolia had 2 hits, one a 2026-10-05 comment listing searchpartyd among 693 processes on someone's Mac. For a process that runs on every Mac, few people write about it.

If yours is busy, check for the BeaconStoreActor error first:

/usr/bin/log show --last 1h --predicate 'process == "searchpartyd"' --info \
  | grep -c BeaconStoreActor
/usr/bin/log show --last 1h --predicate 'process == "searchpartyd"' --info \
  | grep -c "Ignoring advertisements"

A large first count matches the forum bug. A large second count means it is mostly turning away Bluetooth traffic, as it does here. The process is root-owned, so killing it needs sudo, and launchd starts it again on the next Mach call. I did not kill it, disable it, or turn Bluetooth off for this test. If you use a third-party Bluetooth adapter, the bluetoothd allowlist decides whether this daemon sees anything at all.

FAQ

What is searchpartyd on Mac?

searchpartyd is the macOS daemon behind the Find My network's offline finding. It manages beacon keys and receives Bluetooth sightings of nearby Apple devices and AirTags from bluetoothd. It runs as root from /usr/libexec/searchpartyd, launched by /System/Library/LaunchDaemons/com.apple.icloud.searchpartyd.plist, with a per-user helper called searchpartyuseragent.

Is searchpartyd a virus?

No. searchpartyd is part of macOS. The real binary is /usr/libexec/searchpartyd on the read-only system volume, and launchd starts it from Apple's own plist. A process with that name running from any other folder would be worth investigating.

Does turning off Find My stop searchpartyd?

Not on the Mac I tested. With Find My Mac off and no Apple Account, both searchpartyd and searchpartyuseragent kept running for 21 days. searchpartyd still received Bluetooth advertisements and logged Ignoring advertisements while finder is off for each batch, at a cost of about 38 seconds of CPU a day.

Measured on 2026-10-19 on one headless Mac mini (Mac16,10, M4, macOS 26.4.1 build 25E253, up 21 days) with Find My Mac off and no Apple Account, as an admin user without sudo. CPU figures are from ps. Log counts come from one /usr/bin/log show --info --debug --last 21d export of searchpartyd and searchpartyuseragent (56,142 lines; Info-level detail only from 19:50:08) and one five-minute log stream at 21:02. The hourly table counts activity records and assumes one per batch outside the window where I checked it. Find My state is from the agent's defaults domain and nvram. Design background is from Apple's Platform Security guide; community counts are from the Stack Exchange API and HN Algolia on 2026-10-19.