LSyncer icon LSyncer
macOS Development

iCloud Sync Too Slow on Mac: How Developers Can Speed It Up

iCloud sync too slow on Mac? Find developer folders causing churn, clean node_modules, and use filtered sync for faster backups.

Mac developer frustrated by slow iCloud sync while a development folder creates thousands of tiny files

iCloud sync too slow on Mac is annoying for anyone, but it is especially painful when your work folder is a software project. You save one file, install a package, switch a branch, or rebuild the app, and iCloud Drive spends the next hour chewing through a queue that never seems to shrink.

The usual advice is to restart the Mac, toggle iCloud Drive, or wait. Sometimes that helps. For developers, though, slow iCloud sync is often not a temporary glitch. It is a workload problem. iCloud is trying to treat dependency folders, Git internals, virtual environments, build output, cache directories, and normal source files as the same kind of data. They are not the same.

A normal document folder may contain a few hundred files. A medium Node.js project can contain 80,000 files after npm install. A Python project with .venv, caches, notebooks, and test output can create the same kind of churn. The raw size may not look scary in Finder, but the file count is brutal.

Why iCloud sync too slow on Mac usually means too many file events

Cloud sync tools do more than upload bytes. When a file changes, macOS has to notice the change, update metadata, decide whether the file is local or cloud-backed, schedule sync work, upload or download data, and reconcile state with the server. That is reasonable for photos, PDFs, Keynote decks, and notes.

Development folders behave differently. Package managers and build tools create short bursts of filesystem chaos:

  • npm install, pnpm install, and yarn install write thousands of files under node_modules.
  • git checkout, git rebase, and git pull update files under .git and often rewrite working-tree files.
  • python -m venv .venv creates an entire local Python environment that can be recreated from requirements.txt or pyproject.toml.
  • Build tools rewrite dist, build, .next, coverage, target, and cache folders over and over.

That is why iCloud Drive can feel randomly slow even when your internet connection is fine. The bottleneck may be local scanning, hashing, file provider bookkeeping, Spotlight indexing, or server-side reconciliation. Upload bandwidth is only one part of the story.

How developer folders slow down iCloud sync on Mac A developer action creates many file events, iCloud processes each event, generated folders keep changing, and the sync queue falls behind. dev action install, build, checkout branch iCloud work metadata, hashes, uploads, conflicts slow sync queue falls behind
Slow iCloud sync is often a queue problem caused by file events, not a simple bandwidth problem.

First, confirm the slow sync is really iCloud

Before changing your project layout, check what is actually busy. Open Activity Monitor and sort by CPU, then by Network. The iCloud-related processes you will often see are bird, cloudd, and fileproviderd. Spotlight processes such as mds and mdworker may also spike because they are indexing the same files iCloud is trying to sync.

From Terminal, this gives you a quick view:

ps aux | egrep 'bird|cloudd|fileproviderd|mds|mdworker' | grep -v grep

Then check whether your project has the kind of file graph that makes iCloud miserable:

find node_modules -type f 2>/dev/null | wc -l
find .git -type f 2>/dev/null | wc -l
find .venv venv -type f 2>/dev/null | wc -l
find .next dist build coverage target -type f 2>/dev/null | wc -l

If those commands return five-digit numbers, you have found a likely cause. You can also look for files that are changing constantly:

find . -type f -mmin -10 | head -50

That command shows files modified in the last ten minutes. If the list is mostly build output, caches, or dependencies, syncing the whole project through iCloud is the wrong shape of workload.

Abstract iCloud sync bottleneck clogged by thousands of tiny developer dependency files
The slowdown often comes from tiny files and metadata churn, not from one huge upload.

Fix 1: pause the churn before you touch iCloud settings

If iCloud is already behind, do not keep feeding it. Stop dev servers, build watchers, test watchers, bundlers, and package installs. Anything that rewrites files every few seconds makes the queue harder to drain.

Common offenders:

  • npm run dev, vite, next dev, and webpack watchers
  • pytest --watch, Jest watch mode, and coverage tools
  • local databases writing under the project directory
  • generators that write screenshots, logs, reports, or temporary files into synced folders

Once the writers stop, give iCloud a few minutes. If the queue starts draining, the issue was not mysterious. Your tools were producing changes faster than iCloud could process them.

Fix 2: move active repositories out of iCloud Drive

The best fix is also the boring one: do not develop inside iCloud Drive. Put active repositories in a local folder such as:

~/Developer
~/Code
~/Projects

Use Git for source history and a remote host such as GitHub, GitLab, or your own server for collaboration. Use iCloud for documents, exports, notes, and archived project copies if you want, but keep the live working tree local.

This change alone solves a surprising number of slow-sync cases. iCloud stops seeing node_modules, .git, .venv, and build output as live cloud data. Your editor, package manager, test runner, and build tool can write files without making the sync engine chase every change.

Fix 3: clean generated folders before syncing a project copy

If you need a project copy in iCloud, clean it before you put it there. Keep source, docs, assets, config, and lockfiles. Remove generated files that can be recreated.

For Node.js projects:

rm -rf node_modules .next dist build coverage .turbo .parcel-cache
npm install

Do the delete before copying the project into iCloud. Then reinstall dependencies only in the local working copy, not in the synced copy.

For Python projects:

rm -rf .venv venv __pycache__ .pytest_cache .mypy_cache .ruff_cache
python3 -m venv .venv

For Ruby projects:

rm -rf vendor/bundle .bundle tmp/cache log/*.log
bundle install

This is not about saving disk space. It is about avoiding a huge sync queue made of files you do not need on another Mac.

Fix 4: use .nosync carefully

macOS generally treats files and folders ending in .nosync as excluded from iCloud Drive sync. That can help for scratch folders you control:

mkdir local-cache.nosync
mkdir tmp-exports.nosync
mkdir playground-data.nosync

Be careful with dependency folders. Renaming node_modules to node_modules.nosync will break Node's module resolution unless you add symlinks or change the workflow. That usually creates more problems than it solves.

Use .nosync for folders your own tools can reference directly. Do not use it as a magic exclude rule for package-manager internals unless you have tested the project after the rename.

Fix 5: use filtered sync instead of making iCloud handle everything

If you want a backup or mirror of your projects, sync the parts that matter. Skip the parts that are easy to recreate. rsync can do this well if you are comfortable maintaining the command:

rsync -av --delete \
  --exclude 'node_modules/' \
  --exclude '.git/' \
  --exclude '.venv/' \
  --exclude 'venv/' \
  --exclude '.next/' \
  --exclude 'dist/' \
  --exclude 'build/' \
  --exclude 'coverage/' \
  ~/Developer/my-app/ ~/Backups/my-app/

Run a dry run first, especially with --delete:

rsync -avn --delete \
  --exclude 'node_modules/' \
  ~/Developer/my-app/ ~/Backups/my-app/

Look at the output before you remove -n. A wrong trailing slash or destination path can copy to the wrong place or delete files you meant to keep.

Where Lsyncer fits

Lsyncer is for the developer who wants that filtered workflow without babysitting shell scripts. It is a native macOS app that syncs folders while skipping the common junk: node_modules, .git, virtual environments, build folders, and caches. You choose the source, destination, exclusions, and schedule.

It will not make iCloud Drive a better realtime sync engine for live dependency trees. That is not the point. The better workflow is to keep active projects local, sync a clean copy somewhere useful, and leave generated folders on the machine that generated them.

Good fit

  • You want clean project backups without dependency folders.
  • You prefer a macOS app over a custom rsync script.
  • You want scheduled runs and visible sync status.
  • You like one-time purchases. Lsyncer is $19.99, not a subscription.

Not a good fit

  • You need Dropbox-style realtime collaboration.
  • You want every generated file mirrored exactly.
  • Your existing backup script is tested and you enjoy maintaining it.
  • You need team permissions, comments, file sharing, or cloud conflict resolution.
Clean filtered folder sync workflow where source files are backed up and generated dependency folders stay local
A filtered sync setup backs up the code you care about and leaves rebuildable junk out of the queue.

Best practices to speed up iCloud sync for developer workflows

  • Keep live repos local. Use ~/Developer or ~/Code for active projects.
  • Do not sync dependency folders. Keep lockfiles such as package-lock.json, pnpm-lock.yaml, requirements.txt, and Gemfile.lock. Recreate dependencies from those.
  • Keep build output out of cloud folders. Folders like .next, dist, build, coverage, and target are usually disposable.
  • Do not run watch mode inside iCloud Drive. Watchers are designed to rewrite files quickly. Cloud sync engines are designed to preserve files safely. Those goals clash.
  • Use filtered backups for projects. Sync source and config, not every generated artifact.
  • Check file counts before blaming the network. If a folder contains tens of thousands of files, slow sync is expected.

Related reading

FAQ

Why is iCloud sync so slow on my Mac?

iCloud sync can be slow because it is processing many file changes, not just uploading a large file. Developer folders with node_modules, .git, virtual environments, build output, and caches create thousands of filesystem events. iCloud has to scan, track, upload, and reconcile those changes.

How do I speed up iCloud sync on Mac?

Stop active file writers, move live development projects out of iCloud Drive, remove generated folders from synced copies, avoid running build watchers inside iCloud, and use filtered sync for project backups. Restarting may help a stuck daemon, but it will not fix a folder that keeps generating thousands of files.

Does node_modules make iCloud Drive slow?

Yes, it can. node_modules often contains tens of thousands of small files. That file count creates metadata and sync overhead even when the folder is not huge in gigabytes. Most teams should recreate node_modules from lockfiles instead of syncing it.

Should I store coding projects in iCloud Drive?

For active development, usually no. Keep repos in a local folder, use Git for source history, and use a filtered backup or sync workflow for the files you want copied elsewhere. iCloud Drive is convenient for documents, but it is a poor fit for live dependency trees and build caches.

Is Lsyncer an iCloud replacement?

No. Lsyncer is a folder sync app for macOS developers. It helps you copy or back up project folders while skipping dependency folders, Git internals, virtual environments, build output, and caches. It is not a cloud collaboration service.