What Is apsd on Mac? The Apple Push Notification Daemon Explained

apsd is the Apple Push Notification service daemon. It is a standard part of macOS, shipped and code-signed by Apple, and it is responsible for maintaining your Mac's connection to Apple's push notification network (APNs). It is not malware, not an optional add-on, and not something you installed.

Its job is narrow but central: it holds open a connection to Apple's push servers so that messages sent to your Mac can arrive the moment they are sent, rather than waiting for some app to check for them. When Apple's infrastructure has something for your machine, it pushes it down that connection, and apsd hands it off to whichever part of the system it belongs to.

A surprising amount of macOS rides on that one pipe. iMessage and FaceTime use it for signalling, so a message or an incoming call arrives instantly. Mail uses it for accounts that support push delivery. Find My depends on it. Calendar, Contacts and Reminders use it to learn that something changed on another device. App Store and third-party app notifications travel through it. On Macs enrolled in mobile device management, MDM commands are delivered the same way, which is why apsd is a hard requirement in managed fleets.

So when you see apsd active on the network, you are usually looking at the plumbing behind a notification you were about to receive — or behind the system quietly confirming that it has nothing new for you.

The reason apsd shows up in every network monitor is architectural rather than accidental. Push notifications only work if the receiving device is reachable, and the way Apple makes a device reachable is to have it open one long-lived connection outward to Apple's servers and keep it there. The connection stays up, mostly idle, exchanging small keep-alive traffic so both ends know it is still good.

That design is deliberately efficient. The alternative — every app that wants to notify you opening its own connection and polling for updates — would mean dozens of sockets, dozens of wakeups, and a measurable hit to battery life and bandwidth. Instead there is a single shared channel for the whole system, and individual apps never talk to their notification backends directly from your Mac. They hand the message to Apple's service, and Apple pushes it down the one connection apsd is holding.

The connection also has to be re-established whenever the network underneath it changes. Waking from sleep, switching from Wi-Fi to Ethernet, joining a different network, connecting or disconnecting a VPN — each of those tears down the existing socket, and apsd immediately builds a new one. If you watch a connection log while moving between networks, apsd will be one of the first processes to reconnect every time.

The endpoints it talks to are Apple-operated push and courier hosts, and APNs traffic is typically carried over TCP port 5223, with fallbacks used when that port is unavailable on a restrictive network. The volume is normally small: many connections, short exchanges, not much total data. That profile — high visibility, low bytes — is what makes apsd conspicuous in monitoring tools without it ever actually being heavy.

apsd is safe. It is a first-party Apple daemon, it has been part of macOS for many years, and its network behaviour is fully explained by the job it does. The reasonable concern is not whether the real apsd is dangerous, but whether the process running under that name on your Mac is the real one — a fair question, since giving malware a boring system-sounding name is an old trick.

You can settle that without special tooling. In Activity Monitor, find apsd in the Network or CPU tab and open the inspector by double-clicking it. The genuine daemon runs as root, lives inside the read-only system volume rather than in your home folder, Applications, or a Downloads directory, and is started by launchd rather than by anything you opened. A copy of apsd sitting somewhere in your user folder would be the anomaly worth chasing.

The stronger check is the code signature. Apple's system binaries are signed by Apple, and on modern macOS the system volume is cryptographically sealed, so a tampered or replaced system daemon is not something an ordinary piece of software can quietly arrange. If you want to confirm it explicitly, macOS ships command-line tooling that reports the signing authority for any binary, and for apsd that authority should come back as Apple.

It is also worth noting what apsd is not. It is not shipping your messages or documents to Apple as content. The push channel carries notification payloads and signalling for the services described above, and for end-to-end encrypted services like iMessage it is a delivery path, not a place where readable content sits. Seeing apsd connect constantly tells you the notification system is working, nothing more.

The honest answer is no, and it is worth being specific about why, because the consequences are unusually broad for a single process.

Blocking apsd does not selectively quiet one noisy app. It severs the one channel every push notification on the Mac arrives through. iMessages stop appearing until something else forces a sync. FaceTime calls stop ringing. Find My loses its ability to respond promptly. Mail accounts that rely on push fall back to periodic checking or stop updating altogether. Calendar, Contacts and Reminders stop hearing about changes made on your other devices. Third-party app notifications simply do not arrive. On a managed Mac, MDM commands from IT stop being delivered, which usually turns into a support ticket rather than a fix.

Worse, the failure mode is confusing rather than obvious. Nothing displays an error saying push is blocked. Things just quietly stop being timely, and weeks later you are debugging why messages arrive on your iPhone but not on your Mac.

If the underlying goal is fewer notifications, the right tools are the ones built for it. System Settings lets you turn notifications off per app, and Focus modes let you suppress them by context or schedule — both stop the interruption while leaving delivery intact. If the goal is less background traffic, apsd is the wrong target anyway: in bytes moved it is one of the lightest talkers on a typical Mac. The processes actually moving data are usually sync clients, backup agents, updaters, and apps with analytics or advertising SDKs, and those are the ones worth looking at.

Occasionally apsd genuinely misbehaves, and the symptom is almost always the same: sustained CPU use and a stream of connection attempts far beyond the quiet keep-alive pattern. What you are usually watching is a reconnection loop — the daemon tries to establish its connection, the attempt fails or is dropped, and it tries again, indefinitely.

The common causes are worth working through in order. A flaky or restrictive network is the most frequent: captive portals, corporate networks that filter the ports APNs uses, or an unstable VPN can all leave apsd unable to complete a connection while it keeps trying. A stale credential is next — a Mail or iCloud account whose authentication has expired often shows up as push churn rather than a clear error, and signing that account out and back in resolves it. Keychain problems affecting the certificates involved in the push connection produce the same pattern. If none of that applies, a restart clears a surprising number of these loops. Check too whether the loop follows a specific network; apsd behaving perfectly at home and looping at the office points at the network, not at your Mac.

The broader point is the one that brought you here. apsd is one daemon among many that macOS runs without asking, and most of them talk to the network — all normal, all opaque by default. macOS gives you almost no visibility into which ones are connecting where, which is why an ordinary process with an unfamiliar name reads as alarming.

That visibility gap is what NetMute closes. It shows real-time per-app and per-process traffic, so you can see what apsd is doing next to everything else on your Mac. Domain-level logging records which domains each process contacted, when, and how much data moved, turning a vague suspicion into a specific answer. When something genuinely should not be talking, the per-app firewall blocks it in one click, with self-expiring temporary rules for when you only want to test whether blocking breaks anything. Network profiles let rules follow the network you are on, and Tracker Shield covers more than 1,100 known tracker domains. The goal is not to block more — as apsd shows, most background traffic is legitimate — but to tell the difference.