The cross-platform reality
Today almost every SME has a mixed device fleet:
- Windows usually makes up the majority (standard workstations, a few servers)
- macOS in marketing, design, engineering, sometimes management
- Linux on CI builders, NAS boxes, the odd server and Pi IoT devices
A tool has to cover them all — not "Windows is the main platform and Mac is in beta". That may have worked until 2020; it doesn't any more.
What should work on every platform
- Screen transmission at ≥30 FPS on modern connections
- Mouse + keyboard in both directions
- Multi-monitor detection
- File transfer
- AES-256 end-to-end
- Hardware-bound device tokens
Platform-specific pitfalls
Windows
What works: everything. Windows has been the main platform for 30 years.
What's awkward:
- UAC prompts on the host: someone has to click "Open anyway". Rare on Windows 11, frequent on older versions.
- TPM 1.2 vs 2.0: older devices (pre-2018) often only have TPM 1.2 — more limited token binding.
macOS Apple Silicon
What works:
- ScreenCaptureKit (instead of Legacy CoreGraphics): capture + system audio in the same stream (system audio not in service mode)
- Secure Enclave for binding the host's sign-in
- Notarisation: no Gatekeeper drama on first start
What's awkward:
- Permission wizard on first connect: the user has to flip 2 toggles in System Settings (Screen Recording + Accessibility). Tools with auto-open-settings + transparent resume after permission change make this painless.
- Intel Macs: not supported by current WinDesk releases; Apple Silicon (M1 or newer) is required.
- Sequoia updates: the ScreenCaptureKit API has changed 2-3 times since it was introduced. Tools that aren't actively maintained break.
Linux
What works:
- .deb / .rpm packages, postinst script for the /dev/uinput udev rule
- TPM 2.0 for binding the host's sign-in (on modern hardware)
- Wayland and X11 as equal display servers
What's awkward:
- Wayland screen capture: needs xdg-portal with
org.freedesktop.portal.ScreenCast. Older distros (pre-Ubuntu 22.04) often buggy. - /dev/uinput permissions: postinst has to set the udev rule + group cleanly. Bad tools require sudo at runtime.
- TPM availability: not every Linux box has TPM. Pi 4/5 doesn't → the token is protected with the system keyring instead.
Raspberry Pi 4/5
What works:
- arm64 .deb for Pi OS Bookworm 64-bit
- Token storage via the system keyring (no TPM)
- Service operation for makers and education labs (graphical session required)
What's awkward:
- Pi 4 with 1 GB RAM is too small → 2 GB minimum recommended
How WinDesk stacks up
In 0.5.0 (May 2026), all four platforms are production-ready:
| Platform | Status | Build |
|---|---|---|
| Windows 10/11 x64 | ✅ Main platform | EV-signed NSIS Setup |
| macOS Apple Silicon (arm64) | ✅ Notarised | Apple Developer ID + notarisation |
| Ubuntu/Debian x64 | ✅ Production | .deb, SHA-256 checksum |
| Fedora/RHEL x64 | ✅ Production | .rpm, SHA-256 checksum |
| Raspberry Pi 4/5 (arm64) | ✅ Production | .deb arm64 |
| Intel Mac (x64) | Not supported | No current release package |
Cross-platform consistency: same UX, same audit logs, one account.
Practical recommendation
If you have a mixed fleet:
- Test with the Free plan on each platform. 2 hours is enough to verify capture + input work.
- Document special setups. Pi running as a service? Record how it was set up, in one central place.
- Pro plan as soon as unattended makes sense. Free is enough for spontaneous help, Pro for regular maintenance.
- Test every build before rollout. Especially Mac updates (Apple likes to change the ScreenCaptureKit API).