Die Cross-Platform-Realität
Heute hat fast jedes KMU eine gemischte Geräte-Flotte:
- 80% Windows (Standard-Workstations, ein paar Server)
- 15% macOS (Marketing, Design, Engineering, manchmal die Geschäftsleitung)
- 5% Linux (CI-Builder, NAS, ein paar Server, Pi-IoT-Devices)
Ein Tool muss alle abdecken — und zwar nicht «Windows ist die Hauptplattform und Mac ist Beta». Das ging bis 2020 vielleicht; heute nicht mehr.
Was auf jeder Plattform funktioniert (sollte)
- Bildschirm-Übertragung mit ≥30 FPS auf modernen Verbindungen
- Maus + Tastatur in beide Richtungen
- Multi-Monitor-Erkennung
- Datei-Transfer
- AES-256 Ende-zu-Ende
- Hardware-gebundene Geräte-Token
Plattform-spezifische Fallstricke
Windows
Was geht: alles. Windows ist seit 30 Jahren die Hauptplattform.
Was klemmt:
- UAC-Prompts beim Host: muss die Verbindung «Trotzdem öffnen»? Bei Windows 11 selten, bei älteren oft.
- TPM 1.2 vs 2.0: ältere Geräte (vor 2018) haben oft nur TPM 1.2 — eingeschränktere Token-Bindung.
macOS Apple Silicon
Was geht:
- ScreenCaptureKit (statt Legacy-CoreGraphics): hardware-beschleunigte Bildaufnahme + System-Audio im selben Stream
- Secure Enclave für Token-Bindung: Diebstahlsicher
- Notarisation: kein Gatekeeper-Drama beim ersten Start
Was klemmt:
- Berechtigungs-Wizard beim ersten Connect: User muss in Systemeinstellungen 2 Toggles umlegen (Bildschirmaufnahme + Bedienungshilfen). Tools mit Auto-Open-Settings + transparenter Wiederaufnahme nach Permission-Änderung machen das schmerzlos.
- Intel-Macs (vor 2020): osx-x64-Build oft nicht offiziell, manuell zu builden.
- Sequoia-Updates: ScreenCaptureKit-API hat sich 2-3 mal geändert seit Einführung. Tools die nicht aktiv pflegen, brechen.
Linux
Was geht:
- .deb / .rpm-Pakete, postinst-Skript für /dev/uinput-udev-Regel
- TPM 2.0 + tpm2-tools für Token-Bindung (auf moderner Hardware)
- Wayland und X11 als gleichwertige Display-Server
Was klemmt:
- Wayland-Bildschirmaufnahme: braucht xdg-portal mit
org.freedesktop.portal.ScreenCast. Ältere Distros (vor Ubuntu 22.04) oft buggy. - /dev/uinput-Permissions: Postinst muss die udev-Regel + Gruppe sauber setzen. Schlechte Tools brauchen sudo zur Laufzeit.
- TPM-Verfügbarkeit: nicht jede Linux-Box hat TPM. Pi 4/5 hat keinen → Fallback auf libsecret-keyring.
Raspberry Pi 4/5
Was geht:
- arm64-.deb für Pi OS Bookworm 64-bit
- libsecret-Token-Storage (kein TPM, aber GNOME-Keyring-äquivalent)
- Headless-Setups für Maker, IoT, Education-Labs
Was klemmt:
- Pi 4 mit 1 GB RAM ist zu klein → mind. 2 GB empfohlen
- Bei Maker-Distros (DietPi, custom Buildroot): libsecret oft nicht vorhanden, Token-Storage muss manuell konfiguriert werden
Wie WinDesk hier abschneidet
In 0.5.0 (Mai 2026) sind alle vier Plattformen produktiv:
| Plattform | Status | Build |
|---|---|---|
| Windows 10/11 x64 | ✅ Hauptplattform | EV-signiert NSIS Setup |
| macOS Apple Silicon (arm64) | ✅ Notarisiert | Apple Developer ID + Notarization |
| Ubuntu/Debian x64 | ✅ Produktiv | .deb (signiert) |
| Fedora/RHEL x64 | ✅ Produktiv | .rpm (signiert) |
| Raspberry Pi 4/5 (arm64) | ✅ Produktiv | .deb arm64 |
| Intel-Mac (x64) | 🔧 Auf Anfrage | osx-x64-Build kann gebaut werden |
Cross-Platform-Konsistenz: gleiche Bedienung, gleiche Audit-Logs, ein Account.
Praktische Empfehlung
Wenn Sie eine gemischte Flotte haben:
- Test mit dem Free-Plan auf jeder Plattform. 2 Stunden reicht zum Verifizieren, dass die Bildaufnahme + Eingabe funktionieren.
- Special-Setups dokumentieren. Pi-Headless? Zentral notieren wie’s eingerichtet wurde.
- Pro-Plan, sobald Unattended sinnvoll wird. Free reicht für Spontan-Hilfe, Pro für regelmässige Wartung.
- Jeden Build vor Roll-out testen. Vor allem Mac-Updates (Apple ändert ScreenCaptureKit-API gerne).