The cross-platform reality
Today almost every SME has a mixed device fleet:
- 80% Windows (standard workstations, a few servers)
- 15% macOS (marketing, design, engineering, sometimes management)
- 5% Linux (CI builders, NAS, a few servers, Pi IoT devices)
A tool has to cover them all — not “Windows is the main platform and Mac is in beta”. That worked maybe until 2020; not 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 at the host: should the connection “open anyway”? On Windows 11 rare, on older versions frequent.
- 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): hardware-accelerated capture + system audio in the same stream
- Secure Enclave for token binding: theft-resistant
- Notarisation: no Gatekeeper drama on first start
What’s awkward:
- Permission wizard on first connect: 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 (pre-2020): osx-x64 build often not official, has to be built manually.
- Sequoia updates: the ScreenCaptureKit API has changed 2-3 times since introduction. Tools that aren’t actively maintained break.
Linux
What works:
- .deb / .rpm packages, postinst script for the /dev/uinput udev rule
- TPM 2.0 + tpm2-tools for token binding (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 → fallback to libsecret-keyring.
Raspberry Pi 4/5
What works:
- arm64 .deb for Pi OS Bookworm 64-bit
- libsecret token storage (no TPM, but GNOME-Keyring equivalent)
- Headless setups for makers, IoT, education labs
What’s awkward:
- Pi 4 with 1 GB RAM is too small → 2 GB minimum recommended
- On maker distros (DietPi, custom Buildroot): libsecret often missing, token storage has to be configured manually
How WinDesk stacks up
In 0.5.0 (May 2026), all four platforms are production:
| 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 (signed) |
| Fedora/RHEL x64 | ✅ Production | .rpm (signed) |
| Raspberry Pi 4/5 (arm64) | ✅ Production | .deb arm64 |
| Intel Mac (x64) | 🔧 On request | osx-x64 build available on request |
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 headless? Centralise how it was set up.
- 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).