Current prototype · technical overview
How it's built
This describes the development build as it exists today, on one pair of machines. It is not a claim that every device, application or network is supported.
What it does
A Windows application window is moved onto a virtual display, captured, encoded on the Windows GPU and presented on the Mac as an ordinary macOS window — several at once, stacking and overlapping alongside native Mac apps. The application keeps running on Windows. Keyboard and pointer input travels back to it. Dragging a window between the machines works the way it does between two monitors: it spans both screens mid-drag.
The stack
Windows — Windows Graphics Capture for window capture, an IddCx virtual display driver, NVENC for HEVC, H.264 and AV1 encoding, Win32 input injection.
Transport — QUIC in Rust, with a pinned certificate fingerprint. A reliable lane carries control messages; a datagram lane carries video with Reed–Solomon forward error correction, so a lost packet costs one frame instead of stalling the stream.
macOS — a Swift agent using VideoToolbox for decoding, ScreenCaptureKit for Mac-side capture and CGEvent for input.
Authentication — requests are signed with HMAC-SHA256 and carry a nonce and timestamp to block replays. Clipboard contents are encrypted with AES-GCM. Paired secrets are stored in Windows DPAPI and the macOS Keychain.
Measurements
A median of just under 10 ms from capture on the Windows PC to display on the Mac, at 3456×2144 in 10-bit 4:4:4 HDR over wired Ethernet.
Full measurements →What it needs permission to do
Windows: input injection, window capture and a virtual display driver. macOS: Accessibility for input control, Screen Recording for capturing Mac content. Both remain visible and revocable in macOS settings.
What a server is for
Licence checks and software updates use a server. Screen content, keystrokes, pointer input and clipboard contents stay on the direct connection between your own two machines.
Known limitation: first-time pairing
The pairing flow currently returns the shared secret over plain HTTP on the local network. Anyone watching that network at that moment could capture it. The hardened replacement — ephemeral ECDH with pairing-code confirmation — is designed but not built. Pair only on a network you control until it ships.
Bugs
There are more than I can usefully list. This has run on one pair of machines, and most of what breaks will break on hardware I have never seen.
I can point at the ones I know. What I can't do alone is find the ones I don't — that takes someone who can read the system, follow a symptom back to its cause, and decide what actually matters.
The hard parts
I'm one person, and some of this is beyond what I can take further alone. A few of the open ones:
- AMD and Intel encoder paths. Everything currently runs on NVENC.
- Mixed-DPI setups — keeping a window the same size as it crosses between machines running at different scales.
- Concurrent hardware encoder limits, and what to give up when a machine runs out of them.
- Driver attestation and a signed installer.
But the list isn't the job. The job is being the person who decides what belongs on it.
If this is the kind of thing you work on, I'd like to talk.
Get in touch →Documentation for an early prototype. It will change as the security model and hardware support mature.