/status
Every claim carries its evidence.
105 cells, each naming the strongest evidence that exists for it and footnoted with what was actually run. This page is generated from the README table and CI fails if the two disagree.
15 cells verified on hardware. 41 still waiting.
A cell turns dev when someone runs it on a real device
and reports what happened — the script is
DEVICE_CHECKLIST.md.
One iPhone and one Mac account for every dev tag below;
five columns have never run on a device at all.
- macOS Device-verified: 7 cells
- iPhone Device-verified: 6 cells
- Browser Device-verified: watch page, real HTTP
- iPad Never tried — should behave like iPhone I have one →
- Android Has never completed a pairing I have one →
- Linux Cross-compiles; never executed on Linux I have one →
- tvOS Builds; never run on an Apple TV I have one →
- Windows Deliberately on hold — plan 08
Colour here means evidence, not progress.
Hover or focus any tag for its definition; the numbers link to the footnote that says what was actually run. Untick a platform to narrow the table.
| Capability | macOS | iOS/iPadOS | tvOS | Android | Linux | Windows 2 | Browser |
|---|---|---|---|---|---|---|---|
| Discover + pair (code + word pair, TOFU) | dev 15 | dev 15 | bld 1 | smoke 3 | E2E 4 | E2E 4 | — |
| File transfer (chunked, resumable, SHA-256) | dev 15 | dev 15 | — | smoke 3 | E2E 4 | E2E 4 | — |
| Clipboard (both directions, explicit) | dev 15 | dev 15 | — | smoke 3 | E2E 4 | E2E 4 | — |
| Input — send (drive a peer) | E2E | dev 15 | — | bld | E2E* 13 | — | — |
| Input — receive (be driven) | dev 15 | wall | — | bld 6 | bld (uinput) | bld (SendInput) | — |
| Screen — source (be watched) | dev 15 | dev (ReplayKit ext) 15 | wall | bld (MediaProjection) | E2E* 13 | — | — |
| Screen — view a peer | dev 15 | dev 15 | bld 1 | bld 8 | E2E* 13 | — | dev (push only) 14 15 |
| Watch and drive, one surface (ADR 0015 absolute pointing) | E2E* | bld 1 | — | bld | E2E* 13 | — | — |
| Push-share + cast to any browser (HLS + QR) | dev (real HTTP) 9 15 | — | — | (browser plays it) | — | — | dev 14 15 |
| Multi-viewer, per-peer view-only/control, live revoke | E2E | bld 1 | bld 1 | — | — | — | — |
| Notifications (source → display) | E2E (display) | bld 1 | — | bld (listener svc) | code 10 | code 10 | — |
| Phone as Bluetooth HID peripheral | wall | wall | — | bld (needs 2 devices) | — | — | — |
| Wi-Fi Aware (link with no router) | wall | bld — flag ON, zero runtime 11 | wall | code 12 | — | — | — |
| Contexts / Routines / on-device suggestions | unit | unit (triggers device-gated) 1 | — | — | — | — | — |
| Extra monitor (virtual display) | code (unsupported/, never compiled) |
— | — | — | — (evdi, design note only) | code (IddCx, no frame path) | — |
No capability matches that filter.
How to read a cell.
The tag is the strongest evidence that exists — not the best intention. Counts are of the 105 cells above.
- E2E
- automated end-to-end over real TLS sockets, same host (loopback) 9 cells
- E2E*
- E2E with a fake at the hardware seam (fake injector / synthetic capturer) 5 cells
- unit
- unit-tested logic 2 cells
- smoke
- Kotlin/JVM in-process session smoke (real crypto, no Android) 3 cells
- bld
- compiles / APK assembles — no runtime evidence 16 cells
- code
- written but unreachable or uninstantiated — weaker than
bld6 cells - wall
- the platform forbids it (documented, not a TODO) 6 cells
- —
- not implemented 42 cells
- dev
- device-verified on real hardware — see ¹⁵ for what was run 15 cells
What the green suite actually proves.
A green suite is not a working device. Every end-to-end test here runs over real TLS sockets on one host, and the two places a fake stands in for hardware are named.
- Swift
- 126 tests — unit and end-to-end over real loopback TLS
- Golden vectors
- 52, byte-identical across Swift, Go and Kotlin
- Kotlin builders
- 18 more vectors pinning its output to Swift's bytes
- Faked seams
- two — the screen capturer and the input injector
- Self-skipped
- the 4-test broadcast suite, while the screen is locked
Every footnote is the README's, word for word.
They are where a cell stops being a colour and starts being something you can go and check. 15 of them, unedited.
- Shared
ConduitKitcore: the logic runs in the loopback E2E suite on macOS; the iOS/tvOS app targets build unsigned (make apple-apps, fourBUILD SUCCEEDEDre-verified today). No session has run on a tvOS device, and any iOS cell not markeddevhas not been exercised on hardware. - Windows: daemon logic only; new Windows work is on hold per plan 08.
- JVM in-process smoke proves the session code with real Ed25519 + pairing math. No Android device has ever completed pairing — the gate everything Android waits behind. Per-capability detail:
android/README.md. - Go daemon logic proven over loopback on a macOS host (Go↔Go pair+transfer test, plus the live Swift↔Go interop suite). The Linux/Windows binaries cross-compile but have never been executed on those OSes.
- The real macOS
CGEventinjector needs Accessibility and a non-sandboxed app (ADR 0005). It has now moved a real cursor — see ¹⁵. - Android input receive is an AccessibilityService; keyboard support is a narrow, documented subset — unsupported keys are refused out loud (
android/README.md). - Real ScreenCaptureKit capture needs the Screen Recording grant. It has now run with that grant — see ¹⁵.
- Decoder +
SurfaceViewexist; no frame has ever been decoded on an Android device. - Includes the browser watch page over real HTTP GETs. AirPlay endpoint is built-in; Google Cast / Matter Casting are real code behind their SDKs (SDK-gated, unvalidated — ADR 0011). HLS runs seconds behind: for watching, not controlling.
- The Go→Swift notification path is E2E-tested on host; the OS hooks (Linux D-Bus / Windows WinRT sources) are stubs.
- Implemented today (2026-07-26): entitlement granted,
_mosis-aware._tcppublished/subscribed over the iOS 26 Network API, same pinned mutual TLS, OS-levelWAPairedDevicepairing UI in the app, flag ON for iOS with runtime self-gating. Compile-verified only — not one Aware byte has ever flowed; needs two Aware-capable iPhones/iPads. Aware-only sessions would carry video on the control-lane fallback (~2.5 Mbps) until plan 08 lands QUIC. - Android's
WifiAwareBackendwas rewritten to be capable of working (2026-07-26) but nothing instantiates it (docs/interop-status.md). - Linux via the Go core (
core/screencast/+conduitview, landed 2026-07-26): Go↔Go loopback E2E on a macOS host — real TLS, real ffmpeg at the codec seam, synthetic frames at the capture seam; lane promotion and control-lane fallback asserted on both ends. All X11 code (capture, window/blit/events), uinput, and real-network reverse dial cross-compile but have never executed on a Linux box — per-row ledger in plan 09, runbook indocs/linux.md. - Browser is not a platform port — there is no browser client. It is what a plain web browser can do with no MOSIS app installed: watch a screen a Mac pushes to it (HLS over real HTTP, URL + QR), and nothing else. It cannot pair, cannot initiate a pull, and cannot send anything back.
- Device-verified 2026-08-11, hands-on by the author on one real iPhone and one real Mac: pairing, file transfer, clipboard, the iPhone driving the Mac's pointer and keyboard as a trackpad, and screen sharing both directions — so the real
CGEventinjector moved a real cursor and real ScreenCaptureKit capture ran, neither of which had happened before. The browser watch page was used over real HTTP from another device. This was hands-on use, not a fullDEVICE_CHECKLIST.mdwalk. iPad has not been tried (iPhone only), and nothing here touches Android, Linux, tvOS or Windows.