La realtà cross-platform
Oggi quasi ogni PMI ha una flotta di dispositivi mista:
- 80 % Windows (postazioni standard, qualche server)
- 15 % macOS (marketing, design, ingegneria, talvolta la direzione)
- 5 % Linux (CI builder, NAS, qualche server, dispositivi Pi IoT)
Uno strumento deve coprirli tutti — e non « Windows è la piattaforma principale e Mac è in beta ». Andava forse fino al 2020; oggi non più.
Cosa deve funzionare su ogni piattaforma
- Trasmissione schermo a ≥30 FPS su connessioni moderne
- Mouse + tastiera in entrambi i versi
- Riconoscimento multi-monitor
- Trasferimento file
- AES-256 end-to-end
- Token dispositivo legati all’hardware
Insidie specifiche per piattaforma
Windows
Cosa funziona: tutto. Windows è la piattaforma principale da 30 anni.
Cosa inceppa:
- Prompt UAC all’host: la connessione deve « aprire comunque »? Su Windows 11 raro, sui vecchi frequente.
- TPM 1.2 vs 2.0: dispositivi vecchi (prima del 2018) hanno spesso solo TPM 1.2 — binding del token più limitato.
macOS Apple Silicon
Cosa funziona:
- ScreenCaptureKit (invece del Legacy CoreGraphics): cattura immagine accelerata hardware + audio di sistema nello stesso flusso
- Secure Enclave per il binding del token: resistente al furto
- Notarizzazione: niente dramma Gatekeeper al primo avvio
Cosa inceppa:
- Wizard di permessi al primo connect: l’utente deve attivare 2 toggle in Impostazioni di sistema (Registrazione schermo + Accessibilità). Strumenti con auto-apertura impostazioni + ripresa trasparente dopo cambio permessi rendono ciò indolore.
- Mac Intel (prima del 2020): build osx-x64 spesso non ufficiale, da compilare manualmente.
- Aggiornamenti Sequoia: l’API ScreenCaptureKit è cambiata 2-3 volte dall’introduzione. Strumenti non manutenuti attivamente si rompono.
Linux
Cosa funziona:
- Pacchetti .deb / .rpm, script postinst per la regola udev /dev/uinput
- TPM 2.0 + tpm2-tools per binding del token (su hardware moderno)
- Wayland e X11 come display server equivalenti
Cosa inceppa:
- Cattura schermo Wayland: richiede xdg-portal con
org.freedesktop.portal.ScreenCast. Distro vecchie (prima di Ubuntu 22.04) spesso buggy. - Permessi /dev/uinput: il postinst deve configurare pulitamente la regola udev + il gruppo. Strumenti scadenti richiedono sudo a runtime.
- Disponibilità TPM: non ogni box Linux ha un TPM. Pi 4/5 non ne ha → fallback libsecret-keyring.
Raspberry Pi 4/5
Cosa funziona:
- arm64 .deb per Pi OS Bookworm 64-bit
- Storage del token libsecret (niente TPM, ma equivalente GNOME-Keyring)
- Setup headless per maker, IoT, laboratori didattici
Cosa inceppa:
- Pi 4 con 1 GB RAM è troppo piccolo → minimo 2 GB raccomandati
- Su distro maker (DietPi, custom Buildroot): libsecret spesso assente, lo storage del token deve essere configurato manualmente
Come si posiziona WinDesk
In 0.5.0 (maggio 2026) tutte e quattro le piattaforme sono produttive:
| Piattaforma | Stato | Build |
|---|---|---|
| Windows 10/11 x64 | ✅ Piattaforma principale | Setup NSIS firmato EV |
| macOS Apple Silicon (arm64) | ✅ Notarizzato | Apple Developer ID + notarizzazione |
| Ubuntu/Debian x64 | ✅ Produttivo | .deb (firmato) |
| Fedora/RHEL x64 | ✅ Produttivo | .rpm (firmato) |
| Raspberry Pi 4/5 (arm64) | ✅ Produttivo | .deb arm64 |
| Mac Intel (x64) | 🔧 Su richiesta | Build osx-x64 su richiesta |
Coerenza cross-platform: stessa UX, stessi audit log, un account.
Raccomandazione pratica
Se hai una flotta mista:
- Testa con il piano Free su ogni piattaforma. 2 ore bastano per verificare che cattura immagine + input funzionino.
- Documenta i setup speciali. Pi headless? Centralizza come è configurato.
- Piano Pro non appena l’unattended diventa sensato. Free basta per aiuto spontaneo, Pro per manutenzione regolare.
- Testa ogni build prima del rollout. Specialmente aggiornamenti Mac (Apple ama cambiare l’API ScreenCaptureKit).