Your Mac has two Downloads folders. Here's how I made them one.

On a Mac, almost every app downloads into `~/Downloads`. It's local — and, surprise, it **never** syncs to iCloud. The "Desktop & Documents in iCloud" feature only covers Desktop and Documents; Downloads is deliberately left out.

On an iPhone or iPad, Safari saves into a *different* folder: **`Downloads` inside iCloud Drive** (`~/Library/Mobile Documents/com~apple~CloudDocs/Downloads` on the Mac). That one syncs everywhere.

So you end up with two folders both called "Downloads," and the file you grabbed on your phone is nowhere to be found on your Mac. Years of mild, low-grade confusion.

The only real single path

You can't make `~/Downloads` appear on iOS — it simply doesn't sync. The one folder visible on Mac **and** iPad **and** iPhone is the iCloud Drive one. So unifying means making the Mac use *that* as its Downloads too.

The clean way is a symlink — replace `~/Downloads` with a link to the iCloud one. Except it fails:

$ ln -s ~/Library/Mobile\ Documents/com~apple~CloudDocs/Downloads ~/Downloads
# ...rm ~/Downloads → Permission denied

The gotcha: a hidden "deny delete" ACL

`~/Downloads` is a protected special folder. `rm`/`rmdir` returns *Permission denied* even as the right user, even with sandboxing off. The reason is an access-control entry macOS stamps on it:

$ ls -lde ~/Downloads
 0: group:everyone deny delete

That ACL explicitly forbids deleting the folder. Strip it and the folder becomes replaceable:

# Move whatever's in ~/Downloads into the iCloud folder FIRST.
chmod -N ~/Downloads     # remove the ACL
rmdir   ~/Downloads      # now allowed
ln -s "$HOME/Library/Mobile Documents/com~apple~CloudDocs/Downloads" ~/Downloads

Now `~/Downloads` *is* the iCloud one. Every Mac download lands in the same place your phone uses, and Finder's sidebar still opens it from the link — though, as we'll see, it quietly stops showing the special Downloads glyph.

Bonus: putting the icon back

After the swap, the folder shows up plain — the blue Downloads-with-an-arrow icon is gone. macOS keeps that icon in CoreTypes; re-apply it as a custom folder icon:

ICNS="/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/DownloadsFolder.icns"
DIR="$HOME/Library/Mobile Documents/com~apple~CloudDocs/Downloads"
osascript -e 'use framework "AppKit"' \
  -e "set i to current application's NSImage's alloc()'s initWithContentsOfFile:\"$ICNS\"" \
  -e "current application's NSWorkspace's sharedWorkspace()'s setIcon:i forFile:\"$DIR\" options:0"
killall Finder

That brings the icon back **in a Finder window, in Get Info, on the Desktop** — anywhere the folder is drawn from its own custom icon. But there's one place it stubbornly won't return, and it took an experiment to understand why.

The one icon you can't get back: the sidebar glyph

In the Finder sidebar, "Downloads" keeps showing a plain folder — no download arrow — no matter how many times you re-apply that `.icns`. That's because the sidebar glyph **was never a custom icon to begin with.** macOS renders the sidebar Favorites with its own system symbols, and it only grants the folder-with-an-arrow to a folder it recognizes as the *home Downloads known-folder*. A symlink resolves to a foreign path inside iCloud Drive, so that identity is lost, and you get the generic folder symbol — tinted by your accent color. No custom icon can override it.

So I tried to outsmart it. What if `~/Downloads` weren't a symlink but a real **mount point** — say a `fuse-t` passthrough backed by the iCloud folder? A mount point is a real directory at the real path; surely the OS would recognize it. To test the theory without building anything, I mounted a throwaway APFS volume straight onto `~/Downloads`:

hdiutil create -size 30m -fs APFS -volname Downloads -ov /tmp/spike.dmg
rm ~/Downloads                                   # drop the symlink
hdiutil attach /tmp/spike.dmg -mountpoint ~/Downloads
killall Finder

The sidebar got *worse*, not better. Favorites → "Downloads" was **still a plain folder, still no arrow** — sitting right next to Desktop and Documents, which proudly wore their special glyphs. And a *second* "Downloads" appeared down in **Locations as an ejectable volume**, complete with a ⏏️. The mount earned none of the known-folder magic and added clutter on top.

The lesson held: **the native Downloads glyph is welded to a real directory at `~/Downloads` that the OS recognizes as the Downloads known-folder.** A symlink doesn't qualify. A mount point doesn't qualify. And the bytes can only live in one place — so a regular user can't have both the native sidebar glyph *and* downloads physically inside iCloud Drive. (Restore your symlink after the experiment: `hdiutil detach ~/Downloads -force; rm -rf ~/Downloads; ln -s "$HOME/Library/Mobile Documents/com~apple~CloudDocs/Downloads" ~/Downloads`.)

That looked like the end — filesystem physics, case closed. Except one detail kept nagging. Desktop and Documents were sitting *right there* in the same sidebar, iCloud-synced, glyphs intact. If this were truly impossible, how do *they* do it?

Going deeper: how Desktop & Documents pull it off

Turn on "Desktop & Documents Folders" in iCloud and something quietly remarkable happens: your bytes move to iCloud, yet `~/Desktop` and `~/Documents` stay **real directories at their home paths, with their special glyphs intact.** They never became symlinks. So what's the trick?

$ ls -ld@ ~/Documents
drwx------@ ... /Users/you/Documents
  com.apple.file-provider-domain-id        # ← tagged into a File Provider
$ xattr -p com.apple.file-provider-domain-id ~/Documents
com.apple.CloudDocs.iCloudDriveFileProvider/<UUID>

The folder stays put and gets enrolled into the **CloudDocs File Provider** via an extended attribute. File Provider then syncs its contents *in place* — no symlink, no move, known-folder identity untouched. (The `Documents` you see *inside* iCloud Drive is just a hidden symlink pointing back the other way, for display.)

So the clean mechanism absolutely exists. The only question is whether it'll take a third folder.

The two locks

**Lock 1 — the allowlist.** Ask the File Provider daemon what it's willing to replicate:

$ fileproviderctl dump | grep 'KF:'
  + supported KF: desktop,documents
  + replicated KF: desktop,documents

`KF` = Known Folders. The daemon hard-codes exactly two — desktop and documents — and Downloads simply isn't on the list. There's no `fileproviderctl` subcommand to add one.

**Lock 2 — you can't forge the enrollment.** Fine, I'll set that xattr on a folder myself and see if the daemon adopts it:

$ xattr -w com.apple.file-provider-domain-id "com.apple.CloudDocs...." ~/test
xattr: [Errno 1] Operation not permitted
$ sudo sh -c 'echo running as $(whoami); xattr -w com.apple.file-provider-domain-id "…" ~/test'
running as root
xattr: [Errno 1] Operation not permitted        # ← root, and still denied

Even as **root**. That attribute lives in a SIP-restricted namespace; it can only be written by a process holding the right entitlement — which means `fileproviderd` and nothing else. SIP gates on entitlement, not on uid, so `sudo` buys you nothing.

And the obvious shortcut — drop a symlink *into* iCloud Drive pointing back at a real local Downloads, the mirror image of what Apple does for Documents — fails too. iCloud doesn't follow it; it uploads the **symlink itself as a 28-byte dead file** (just the path string). On the iPhone you get a "symbolic link" that opens to nothing.

It's a one-line allowlist, not a law of nature

So the real verdict, after walking every door: a **double lock**. SIP stops you forging the enrollment; and even if you could, the daemon's allowlist would refuse a `downloads` known-folder anyway. Both locks are Apple's — and *both are Apple's to open.* The entire machine that would make this work already ships and runs every day for Desktop and Documents. Downloads is, almost literally, one string away from the same treatment.

If you want both the native glyph *and* synced downloads **today**, the only path left is to fake the File Provider yourself: keep `~/Downloads` a real folder (glyph stays) and run a tiny background job that `clonefile`s new arrivals into the iCloud Downloads folder. APFS clones share blocks, so it's nearly free on disk — I measured **4 KB** to "copy" a 200 MB file. But it's a two-way sync engine with every classic hazard (loops, conflicts, delete propagation): a lot of hand-built machinery to reproduce something the OS could grant with one allowlist entry.

The newest casualty: AirDrop lands in `/tmp` — then deletes itself

Months of this working fine, then a new symptom: files I AirDropped from my phone weren't in Downloads at all. They were piling up in **`/private/tmp`** — and a few days later, gone without a trace.

The symlink again, wearing a different hat. Here's the tell that sends everyone down the wrong path:

$ touch ~/Downloads/test    # from Terminal
# → succeeds. So the folder "is writable," right?

Terminal writes straight through the symlink into iCloud Drive, so the folder *looks* perfectly writable and you cross permissions off the list. But AirDrop isn't Terminal. Incoming transfers are handled by **`sharingd`**, which runs **sandboxed** — and that changes everything. Its container is entitled to write the real *home Downloads known-folder*, but a symlink that resolves into `com~apple~CloudDocs` lands outside that grant: CloudDocs writes go through a brokered File Provider path `sharingd` holds no entitlement for. So `sharingd` stages the transfer in the one place it *can* write — `/private/tmp` — and the final hand-off into "Downloads" silently fails. The file is stranded in tmp. (This is the same sandbox-vs-symlink fault line as the glyph, just with teeth: there it cost an icon, here it costs the file.)

That alone you'd eventually find. The cruel part is a *second* daemon you didn't know was running:

$ cat /System/Library/LaunchDaemons/com.apple.tmp_cleaner.plist
#   StartCalendarInterval → Hour 0      (every day at midnight)
$ strings /usr/libexec/tmp_cleaner | grep -E 'days|atime'
daily_clean_tmps_days="3"
args="-atime +3 -mtime +3 -ctime +3"

`/usr/libexec/tmp_cleaner` — the modern replacement for the old `/etc/periodic/daily/clean-tmps`, which no longer exists on recent macOS — sweeps `/tmp` every night at 00:00 and removes anything whose atime, mtime **and** ctime are all older than three days. So an AirDropped file you didn't immediately notice doesn't just go to the wrong place: it **quietly deletes itself within 72 hours.** A file you sent yourself, gone, no error, no Trash.

So the symlink's cost isn't only cosmetic. It silently breaks every sandboxed app that expects `~/Downloads` to be a real directory it's entitled to — AirDrop today, and that's unlikely to be the last one. Which, notice, is the one thing the *keep-`~/Downloads`-real-and-clone* approach above gets right for free: a real folder is a folder `sharingd` can write, so that design fixes AirDrop and unifies downloads in one move. The symlink trades that away.

The honest caveats

Convenient, but not free:

• **AirDrop (and other sandboxed savers) can't write through the symlink** — `sharingd` strands incoming files in `/private/tmp`, where a nightly cleaner deletes them after 3 days. The biggest hidden cost; see above.
• **Everything you download now uploads to iCloud** — big installers included. Mind your storage.
• Files can be **evicted to placeholders** when space is tight; downloads are throwaway, so a tap re-downloads them. (Unlike a Git repo, where iCloud eviction mid-write genuinely corrupts the `.git` — a different horror story entirely.)
• A major macOS update may **restore** `~/Downloads`. If it does, run the three steps again.
• Fully reversible: delete the symlink, recreate a real folder.

So I asked Apple

This isn't a law of nature; it's a policy choice with a one-line fix. The plumbing already exists and runs flawlessly for Desktop and Documents — Downloads just needs to be the third name on an allowlist. So I filed it with Feedback Assistant as **FB23110924**, and the request is exactly that simple: **let Downloads be an iCloud-synced known folder, like Desktop and Documents.**

If you've ever grabbed a file on your phone and found it missing on your Mac, file your own and reference **FB23110924** as a duplicate — dupes are how Apple gauges demand. The more of us who ask for this very basic thing, the likelier they grant it.

Epilogue: I tore it down

I lived with the symlink for a couple of weeks, and the AirDrop discovery was the one that decided it. Not because any single gotcha is fatal — each has a workaround — but because of what the *pile* of them adds up to. The symlink quietly turns `~/Downloads` into something that looks like a folder to you and to Terminal, but isn't quite one to the sandboxed apps and known-folder machinery the OS layers on top of it. Every couple of weeks, something new trips over that gap, and the fix is always one more piece of hand-built scaffolding.

I only ever wanted one modest thing: a file in *the same place* whether I grabbed it on my Mac or my phone. I didn't even need the reverse direction — phone downloads materializing locally on the Mac. Just one place. And the honest math is that buying "one place" through a symlink costs more babysitting than the convenience returns, while the clean version — a real `~/Downloads` plus a tiny one-way clone into iCloud — is a background daemon I'd have to own and maintain *forever*, to reconstitute something the OS could hand me with one allowlist entry.

So I reverted. `~/Downloads` is a real, boring, native folder again — glyph intact, AirDrop working, nothing quietly rotting in `/tmp`. The two-Downloads problem is back, and I've decided I'd rather have that honest split than a clever lie that breaks in a fresh way every fortnight.

The request to Apple still stands — **FB23110924**, let Downloads be an iCloud known folder like Desktop and Documents. That's the only version of "one place" worth having: the one where the OS keeps the folder real. Until then, two folders it is. Sometimes the most restrained answer is to stop out-engineering the platform and just file the bug. 🌊