Why a clipboard manager should be local-first

Think about what actually passes through your clipboard in a given hour: a one-time login code, a snippet of a private message, an API key you're debugging, a draft that hasn't shipped yet. Your clipboard sees more of your sensitive data, more often, than almost any single app on your Mac — and it does so silently, in the background, without you ever deciding to "share" anything.

That's the reason SyncPocket App's very first design decision wasn't a feature. It was: this data does not leave the device.

What that means in practice

• No account. There's nothing to sign up for and nothing to leak in a breach, because there's no server-side account database.
• No telemetry. We don't know what you copy, how often you open the panel, or that you exist. There's nothing phoning home to know.
• Everything on disk, in the open. Your history lives at ~/Library/Application Support/MemoryApp/items.json — a plain, documented format, not an opaque database you can't inspect.
• Confidential content is skipped automatically via the org.nspasteboard convention — the same signal password managers already use to say "don't record this."

Local-first, not disconnected

Local-first never meant your Mac and iPhone had to stay disconnected — it meant we wouldn't connect them at the cost of a server we operate. So iCloud sync now runs on your own private CloudKit database: your Mac and iPhone share one memory, and no SyncPocket App server ever sees it. We took the slower path on purpose — shipping sync once, built this way, instead of a quick sync server we'd have to ask you to trust.

If you're the kind of person who reads privacy policies before installing a clipboard tool — you should be — this is the current policy: your archive stays on your devices and in your own private iCloud when sync is on. Never our infrastructure.