The day before public launch is a good day to be plain about what’s missing. ClipHop v0.1.0 ships with a deliberately narrow surface — plain text and URLs, one phone with one Mac, English only, no third-party audit yet. This post is the honest list of what’s not in v0.1.0 and why each one is the way it is.
We’d rather you know up front than discover a missing feature mid-use and feel misled. None of these are surprises to us; all of them are on the roadmap.
What v0.1.0 does#
So the negative list makes sense, here’s the positive one first:
- Pair one Android phone with one Mac over Bluetooth LE.
- Sync plain text and URLs in both directions.
- AES-256-GCM encryption with X25519 ECDH per-reconnect session keys, authenticated by Ed25519 long-term identity keys in the Keychain / Keystore.
- Identity fingerprint verification at pair time and any time after.
- Clipboard history on each device, biometric-locked on Android.
- Manual send by default; opt-in Auto-send beta with explicit warning about passwords and OTPs.
- Pause sync from either device with one tap (or
⌘Pon Mac). - Works without any network — on planes, captive portals, untrusted WiFi.
That’s the product. Now the deferrals.
Image and file clipboard support#
What’s missing: copy an image on your phone and paste it on your Mac. Same for files. Neither works in v0.1.0.
Why it’s deferred: a clipboard sync tool that handles plain text well over Bluetooth LE doesn’t trivially extend to images and files. Two different design considerations show up:
- Throughput. A typical clipboard image (a screenshot from a phone) is 200 KB–2 MB. BLE LE throughput is roughly 50–200 kbit/s sustained — meaning a single 1 MB image takes ~40–160 seconds to transmit. That’s not a clipboard; that’s a transfer.
- What does the user expect? Copy-paste of an image works locally because the OS keeps the image in RAM. Across devices, you’d want compression, format negotiation (HEIC ↔ JPEG?), thumbnail-then-full-resolution streaming, and a clear “this is going to take a moment” UX. None of that fits the same mental model as text sync.
We want image support to feel right, not just exist. That probably means: a hybrid model where the BLE link is used for control + thumbnail, with a sidechannel (likely Wi-Fi Direct or AWDL on Mac, or a one-time TCP connection over hotspot) for the bulk transfer. Designing and testing that is its own project.
Roadmap: image support is the next major feature after launch. We expect it to be the v0.2 headline.
iOS / iPad support#
What’s missing: there is no iOS app. The full Apple ecosystem with Universal Clipboard already covers iPhone ↔ Mac, but iPhone ↔ Android isn’t covered by anyone, and iPad ↔ Android also isn’t.
Why it’s deferred: not because the protocol doesn’t translate. The protocol is platform-agnostic — same X25519 / AES-GCM / Ed25519 stack. What’s missing is the CoreBluetooth peripheral-side implementation for iOS, which involves Apple’s specific BLE constraints (background-mode entitlements, energy-saving rules, peripheral advertising restrictions) that we haven’t yet written code for.
It’s also worth noting: an iOS app on the App Store needs paid developer-program enrollment and review. We’ve prioritized launching the Mac and Android sides before adding iOS to the project’s surface area.
Roadmap: iOS is the second-largest item after image support. Realistic timeline is months, not weeks.
Multi-pair#
What’s missing: pair one phone with multiple Macs (or one Mac with multiple phones, or any combination beyond a single trusted relationship).
Why it’s held back: this is the deferral we feel most strongly about. Multi-pair is a privacy decision, not just an engineering one.
If your phone is paired to three Macs, what happens when you copy something on the phone? Does it broadcast to all three? Does it pick one based on which is closest? Does it ask? Each answer changes the privacy properties:
- Broadcast to all — your clipboard reaches three devices instead of one. More surface area for a leak.
- Closest one — the phone has to be sure about which is closest, which BLE RSSI doesn’t reliably tell you. Routing bugs would send clips to wrong peers.
- Ask each time — adds friction every paste.
- Auto-select last-active — works well but is opaque to the user.
We don’t have a UX answer we’re happy with yet. Until we do, one active pair at a time is the default. It’s also the configuration that makes the fingerprint mental model simplest: there is one fingerprint to verify, one peer to trust, one identity to defend.
Roadmap: multi-pair is on the post-1.0 list. Image support and iOS come first.
Third-party security audit#
What’s missing: ClipHop’s cryptographic design and BLE implementation have been documented and self-reviewed, but not independently audited.
Why it matters: an audit is the only honest way to claim cryptographic correctness for security-critical code. Internal review catches some bugs but has well-known blind spots.
We’ve designed the system with audit in mind: standards-based primitives (Ed25519, X25519, AES-256-GCM, HKDF), no novel cryptography, all key material in hardware-backed secure storage, documented protocol. See How ClipHop encrypts your clipboard for the design.
Roadmap: an audit is the highest-priority pre-1.0 milestone. Until that audit is complete and any findings are addressed, we are not calling ClipHop 1.0. We will publish the audit report (or its summary), not just a logo or claim, when it’s done.
Localization#
What’s missing: ClipHop is English-only at launch. The Android app’s onboarding and the Mac app’s menus are not translated; the website is not translated.
Why: localization is real engineering work — string extraction, RTL layout testing, currency / date format checks, translator coordination — and the v0.1.0 audience is primarily English-speaking developers and indie users. After we have signal on which languages users actually want, we’ll prioritize accordingly.
Roadmap: post-1.0. If you’d like to help translate, that’s a real contribution we’ll welcome — get in touch.
Accessibility audit#
What’s missing: a complete screen-reader walkthrough of the apps and a full WCAG audit of the website.
Why: we’ve followed reasonable practice — semantic HTML on the website, alt text on every image, keyboard navigation in the Mac menu-bar panel — but haven’t done a structured pass. There are likely gaps we don’t know about.
Roadmap: targeted pass before 1.0. If you use a screen reader and try ClipHop, your bug reports are particularly welcome.
What you can rely on in v0.1.0#
To balance the deferral list with what’s actually solid:
- The pair / unpair / re-pair flow has been tested across ~20 device combinations (see What we tested before launching ClipHop).
- Round-trip latency for plain text and URLs is consistently sub-500 ms in good conditions (see How we measure clipboard latency).
- The cryptographic design uses only standards-based primitives with no novel constructions.
- The privacy guarantees (no cloud, no account, no telemetry, manual-send-by-default) are real, not aspirational.
- The OEM battery-killer fixes for Samsung / OnePlus / Xiaomi are documented and tested.
That’s a meaningful subset to launch with. It’s not “everything,” and we want you to know it’s not.
How to think about v0.1.0#
If your daily workflow is moving plain text and URLs between your Android phone and your Mac, ClipHop v0.1.0 is built for that exact case and we believe it does it well. If your workflow includes images, files, multiple devices, or iOS, we hope you’ll come back for v0.2 and beyond.
Either way: feedback is welcome and will shape the priority list. Bug reports and feature requests go to [email protected] and reach the builder’s phone directly. Launch day is tomorrow on Product Hunt — we’ll see you there.