Most cross-platform apps pick one platform’s APIs and shim the other.
We did the opposite. On macOS, hypershot talks to ScreenCaptureKit. On Windows, it talks to Windows.Graphics.Capture. Each side calls the operating system’s own screen-capture machinery — the same pipeline the OS trusts for its own capture tools — and each side feeds the same shared engine.
The result: both machines run the real thing. Nobody is running a port.
The hard part is knowing what not to share
The capture path is the whole product. A screenshot tool is judged on one number: how long between you pressing the default hotkey and the frame landing under your cursor. So the frame path has to be fast on both OSes, and “fast on both” doesn’t come from one middle layer that works everywhere. It comes from the best path on each OS, meeting in the middle.
On macOS that’s a ScreenCaptureKit stream. Frames arrive as CVPixelBuffers, and we convert them to images on the CPU on purpose: the reticle you watch while framing a shot samples live frames on the GPU, and we would rather the CPU do the conversion than fight the GPU for time. The app targets macOS 14 and up, which is exactly when ScreenCaptureKit became a dependable citizen API instead of a bet.
On Windows that’s Windows.Graphics.Capture through WinRT. Frames land as D3D11 textures, and we hold the texture reference without touching it — cheap — converting to a full-resolution image only when something actually needs pixels. The live preview is even cheaper: a downscaled read of about 2MB instead of a full ~33MB frame. When you export, the encoder is Windows’ own Imaging Component, not a bundled third-party stack. Same shape as the macOS path, different nouns.
Four small interfaces hold the platforms apart
Everything platform-specific in hypershot sits behind four interfaces: the capture engine, the hotkey manager, the permission manager, and the text detector. A factory picks the implementation when the app starts, and everything above that line — the editor, the annotations, the frame scrubber, the overlay — never learns which OS it is running on.
That split decides which bugs are cross-platform and which are local. An annotation that renders wrong renders wrong on both machines, because annotations are shared code. A capture glitch on Windows stays in the Windows engine, because the Windows engine is the only place it can live.
Even the hotkeys disagree
The platform layer is where the operating systems show their scars. macOS reserves ⌘⇧3 through ⌘⇧6 for its own screenshot keys, so we never claim them — the default region-capture hotkey is ⌘⇧2. Windows reserves Win+Shift combos for the shell, so a hotkey registered under one simply never fires; the defaults live in the Ctrl+Shift family instead. The settings screen shows both families, and if the combo you pick is already taken, the app walks you to a free one.
Permissions are the same story, told slower. Both OSes want to ask before a third-party app sees your screen, so hypershot shows you a live permissions window on first launch — each status updating in real time — rather than failing silently the first time you press the hotkey.
What about Linux?
You have noticed the title names exactly two operating systems. That’s deliberate: hypershot does not support Linux today, and we are not going to pretend otherwise.
The reason “no” is not the same as “never” is the split above. Every OS-specific decision lives behind four small interfaces, and everything else — the engine, the editor, the annotations, the export pipeline — is shared. A Linux build means writing one capture engine for Wayland and X11 and one OCR path, and plugging them into a core that already runs everywhere else. That is real work, and we only do real work like that when enough of you want it badly enough.
So here is the straight answer for the Linux readers reading this: we are listening. If hypershot matters to your Linux workflow, tell us — a Linux release is a “first-class or not at all” decision, and enough signal from you is what flips it.
One product on both of your machines
The reason to build it this way is the reason you’d buy the tool: when your life happens on a Mac at home and a Windows machine at work, your capture workflow, your shortcuts, and your annotations carry over intact. You relearn nothing.
Two operating systems. One engine. Neither of your machines gets the compromise build.
Download for macOS or Download for Windows — the parity is in the pixels, not the FAQ.