What is cloudkitdaemon on Mac, and why is it using so much data?

If you have ever opened Activity Monitor on a Mac and noticed a process called cloudkitdaemon sending or receiving hundreds of megabytes in a single session, you are not alone. It is one of the most consistently chatty background processes on a modern macOS install, and it is also one of the most misunderstood.

What cloudkitdaemon actually is

cloudkitdaemon is the system-level process that implements CloudKit, Apple's framework for syncing structured data and files between a user's devices through iCloud. It runs as a launch daemon on every modern Mac, started by launchd at boot, and lives at:

/System/Library/Frameworks/CloudKit.framework/Support/cloudkitd

You will sometimes also see it referenced as cloudd in older macOS releases and in some Apple documentation. On macOS Sonoma (14), Sequoia (15), and the current release line it shows up in Activity Monitor as cloudkitdaemon or cloudd depending on which iCloud feature is making the call.

CloudKit is not a single feature. It is a transport layer that almost every iCloud-backed feature and a long list of third-party apps use to push and pull changes:

• iCloud Drive — file uploads and downloads, file metadata, version history.
• Photos — full-resolution originals, thumbnails, library metadata, shared albums.
• Notes, Reminders, Calendar, Contacts — record-level sync of every change.
• iCloud Keychain — passwords, passkeys, Wi-Fi credentials.
• Messages in iCloud — your iMessage history.
• Third-party apps — Bear, Things, 1Password (legacy), Day One, Ulysses, and many others sync through CloudKit containers.

Every one of those produces traffic that cloudkitdaemon handles.

Why cloudkitdaemon uses so much data

There are three categories of traffic, and they explain almost every "cloudkitdaemon is using too much data" complaint you will ever see.

1. Photos library sync

If you have iCloud Photos turned on and your Mac is set to Download Originals to this Mac (System Settings → Apple ID → iCloud → Photos), every photo and every video you take on any device flows through cloudkitdaemon to your Mac at full resolution. A single iPhone 4K video can be 500 MB. A trip to the beach can be several gigabytes. It happens silently in the background as soon as you join Wi-Fi.

This is the single biggest contributor for most users. If you have a large library, it can easily push tens of gigabytes through cloudkitdaemon in a month without you ever opening the Photos app.

2. iCloud Drive activity

iCloud Drive uploads any change to any file in ~/Library/Mobile Documents/, which includes Desktop and Documents if you have the "Desktop & Documents Folders" option enabled. Every app save, every Xcode build artifact written there, every PDF you scan, every screenshot dropped on your desktop — all of it goes through CloudKit.

Heavy users of apps like Bear or Day One can see cloudkitdaemon spike whenever those apps batch-commit changes.

3. Catch-up syncs and re-indexing

After a macOS update, an Apple ID re-sign-in, or a long offline period, CloudKit performs a catch-up sync. It reconciles the local state with what has changed in iCloud. On a Mac with a large Photos library, this can mean re-downloading thumbnails for tens of thousands of items, even though the actual photos are already cached. It is the #1 cause of "cloudkitdaemon using too much data" reports after a macOS upgrade.

How to investigate cloudkitdaemon's data usage on your Mac

You do not need any third-party tool to confirm what cloudkitdaemon is doing. macOS ships with the visibility built in.

1. Open Activity Monitor (/System/Applications/Utilities/Activity Monitor.app).
2. Click the Network tab.
3. Sort by Sent Bytes or Rcvd Bytes, descending.
4. Find the row labelled cloudkitdaemon (or cloudd).
5. The "Sent Bytes" and "Rcvd Bytes" columns are cumulative since the process started, which on most Macs means since the last reboot.

To narrow down which iCloud feature is responsible, look at the surrounding processes. photoanalysisd and mediaanalysisd spike alongside Photos syncing. bird is the iCloud Drive client; if it is busy, file activity is the source. nsurlsessiond handles Apple's URL session downloads, and it often pairs with cloudkitdaemon during large file transfers.

For a more granular view, the Console app (/System/Applications/Utilities/Console.app) shows CloudKit logs in real time. Search for subsystem:com.apple.cloudkit to see exactly which CloudKit container and which operation is firing.

Is cloudkitdaemon safe to disable?

Short answer: no, not in any practical sense. cloudkitdaemon is a system-protected process. It runs from /System/, which is on the signed system volume (SSV) and read-only since macOS Big Sur. You cannot remove it, and force-quitting it only causes launchd to restart it within seconds.

You can stop it from doing meaningful work by disabling iCloud features one by one in System Settings → Apple ID → iCloud. Turning off Photos, iCloud Drive, Keychain, and Messages in iCloud will essentially silence cloudkitdaemon. But you will also lose those features. For most people the correct move is not "disable iCloud" — it is "let iCloud run, but stop it from saturating my connection or blowing through my tethered data."

How to limit cloudkitdaemon without disabling iCloud

macOS gives you a few coarse levers:

• Optimize Mac Storage in Photos prefs — keeps lower-resolution copies locally, fetches originals only when you open them. This shifts bandwidth from background bulk-sync to on-demand fetches, which is usually less disruptive.
• Pause iCloud Drive from the Apple menu bar (Big Sur+). Useful for short sessions but it resumes automatically.
• Low Data Mode on the active Wi-Fi (System Settings → Wi-Fi → Details → Low Data Mode). This asks background services to throttle, but compliance is voluntary and CloudKit's response to it is inconsistent.

None of those is a hard cap. None of them lets you say "cloudkitdaemon gets at most 2 GB this week." For that you need an enforcement layer outside CloudKit's own logic.

Using DataCever to set a hard quota

This is exactly the gap DataCever is built for. It sits between every macOS process and the network, watches per-process bandwidth, and lets you set a per-app or per-process quota. When the quota is hit, the process is cut off from the network until you reset the session.

For cloudkitdaemon specifically:

1. Open DataCever and find cloudkitdaemon in the Overview list. (It is the #1 most-blocked process across DataCever users, so it is rarely far from the top.)
2. Set a quota — say 5 GB per month, or 500 MB per day if you are on a metered connection.
3. That's it. iCloud keeps working normally until the cap is hit. After that, CloudKit will silently retry until the next reset.

Apple's own iCloud features handle the network being unavailable gracefully — they queue changes locally and replay them later. So a quota is not destructive; it just means cloudkitdaemon finishes its work on your schedule, not its own.

One more thing: cloudkitdaemon on metered connections

If you tether your Mac to an iPhone, macOS already knows the connection is metered and will throttle some background activity. cloudkitdaemon does respect this most of the time — Photos library uploads, for example, pause on a Personal Hotspot. But iCloud Keychain sync, Notes sync, and small CloudKit operations continue unconditionally, and a Photos catch-up can still slip through if conditions change mid-sync. Plenty of people have come home from a trip to a surprise carrier bill because of exactly this.

A hard cap is the simplest insurance against that scenario. iCloud is excellent, but it was designed for a world where bandwidth is unmetered and unlimited — and that world is not where most people actually live.