If you’ve tried to move a link from your Android phone to your Mac recently, you already know the constraint: Apple’s Universal Clipboard is Apple-only, LAN-based tools require shared WiFi, and cloud clipboards route your text through someone else’s servers. Everything else I could find for Android-to-Mac clipboard sync failed on at least one of those three axes.
The clipboard is an unusually sensitive, unusually short-lived piece of data. It carries links, yes — but also passwords, OTPs, diff patches, private snippets, and half-written messages. The right transport has to be ambient, private, and not dependent on any network you don’t control. After working through the options, Bluetooth Low Energy (BLE) was the only one that cleared all three.
Here’s the rationale.
Option 1: iCloud-backed clipboards (Universal Clipboard)#
Apple’s Universal Clipboard uses Bluetooth LE for proximity discovery and then routes the actual clipboard text through iCloud. It’s convenient, but it has two structural limitations that matter here:
- It’s Apple-only. No Android support, not now, not planned. If you’re using an Android phone, Universal Clipboard does nothing for you.
- Your clipboard travels through Apple servers. Apple’s iCloud clipboard is end-to-end encrypted in the architectural sense, but it still requires iCloud to be signed in and available. On a plane? On a captive portal? Behind a corporate firewall with iCloud blocked? It stops working.
For Android-to-Mac clipboard sharing specifically, Universal Clipboard isn’t a design option — it’s ecosystem-locked.
Option 2: LAN-based tools (KDE Connect)#
KDE Connect is excellent engineering. It synchronizes notifications, files, clipboards, battery status, and media across devices on the same local network. We used it for years before building ClipHop, and it’s still the right answer for people whose devices are always on the same WiFi.
But “always on the same WiFi” is a much smaller set than it used to be. Consider:
- Coffee shops and co-working spaces increasingly isolate clients from each other (for good reason). Your phone and your laptop can be on the same SSID and still not route packets between each other.
- Hotel WiFi usually has client isolation on.
- Enterprise networks segment devices by role — your personal phone and your corporate laptop may not share a subnet even on the same floor.
- Airplanes often have WiFi but it’s captive-portal-gated.
- Travel, multiple residences, dual-SIM phones swapping between home and away networks — the assumption that both devices are on the same LAN degrades fast.
LAN clipboard tools also require both devices to have a known IP address, a reachable port, and the app to be running in the background. Every one of those is a potential source of “why isn’t this working?” support.
Option 3: Cloud clipboards#
A third category — “cloud clipboard apps” — solves the platform problem (they work everywhere) but asks you to hand over custody. You sign up, trust their encryption claims, agree to let your clips sit on their servers indefinitely, and hope they don’t get breached.
For a thing as sensitive and short-lived as a clipboard, that’s a bad trade. A cloud clipboard isn’t really a clipboard anymore — it’s a text-sharing SaaS with a clipboard-shaped interface.
Even for cloud clipboards that claim end-to-end encryption, you’re trusting:
- Their key-management implementation.
- Their client apps not to exfiltrate.
- Their business model not to change.
- Their compliance posture to hold up under subpoena.
There’s a material difference between “encrypted in transit” (most clipboards) and “your text never leaves the two devices you own” (what we wanted).
Option 4: Bluetooth LE#
Bluetooth LE sits at the intersection of the constraints we actually have:
- Ambient. No network required. The two devices just need to be within radio range of each other.
- Private. Packets go directly between the two paired devices. No third party sees them, no server is involved, no account is required.
- Universal. Available on essentially every Android phone and every Mac Apple ships. No special hardware.
- Standards-based. BLE is a well-understood, well-attacked, well-specified stack with decades of public cryptanalysis.
That last point matters more than it looks. BLE is not an ad-hoc transport — it’s in every consumer device, scrutinized by researchers, and has a stable pairing model that we build on top of (rather than inventing a new trust model).
The trade-offs we accepted#
No decision is free. BLE’s honest costs:
- Range is about 10–15 meters in typical indoor conditions. If your phone is in the next room over, your pair can drop. For most of us this is fine — we want the clipboard to work when our phone is on the desk, not when it’s in the car two floors down.
- Throughput is much lower than WiFi. For plain text and URLs, you can’t tell the difference — round-trip is sub-second. For large images or files (coming later), WiFi would be faster. We use L2CAP connection-oriented channels where the device supports them (Android 10+, macOS 13+) to move multi-kilobyte clips in a single frame, with a chunked GATT fallback on older hardware.
- Pairing is a one-time cost. Users have to scan a QR or enter a 6-digit code the first time. After that, the pair re-establishes automatically whenever Bluetooth is on and the two devices are in range.
- Two-device pair (for now). v0.1.0 supports one active pair at a time — one phone with one Mac. Multi-pair support is on the roadmap, but we made this an intentional privacy default: your clipboard only reaches one trusted peer, not broadcast to every device you own.
Head-to-head#
| Criterion | Apple Universal Clipboard | KDE Connect | Cloud clipboards | ClipHop (BLE) |
|---|---|---|---|---|
| Android ↔ Mac | ❌ Apple only | ✅ | ✅ | ✅ |
| Works without internet | ❌ iCloud required | ✅ LAN only | ❌ | ✅ |
| Works on captive-portal WiFi | ❌ | ❌ | Depends | ✅ |
| Works on a plane | ❌ | ❌ | ❌ | ✅ |
| No account required | N/A | ✅ | ❌ | ✅ |
| End-to-end encrypted | ✅ via iCloud | ✅ TLS transport | Claimed | ✅ AES-256-GCM |
| Clipboard stays between your two devices | ❌ iCloud routes | ✅ | ❌ | ✅ |
| Identity fingerprint verification | ❌ | ❌ | ❌ | ✅ |
What about WebRTC, Nearby Share, or [other transport]?#
We looked. WebRTC requires a signaling server and TURN fallback — defeats the point. Nearby Share (Google’s) is Android-only and doesn’t target Mac. AirDrop is Apple-only. Wi-Fi Direct doesn’t work cross-vendor reliably. Most “ad-hoc” transports assume identical OS stacks on both sides; BLE is the rare one that doesn’t.
What’s next#
If the trade-offs above sound acceptable for your workflow, the setup guide walks through pairing in about 60 seconds. And if you want the cryptographic detail — how X25519 ECDH, HKDF, AES-256-GCM, and Ed25519 identity keys fit together in ClipHop — that’s worth its own post (coming up next).
The short version of the rationale: Bluetooth LE is the only transport that lets your clipboard travel between two devices without depending on a network you don’t control, an account you don’t want, or a server you’d have to trust. That’s why it’s the one we chose.