Die Cross-Platform-Realität
Heute hat fast jedes KMU eine gemischte Geräte-Flotte:
- Windows stellt meist die Mehrheit (Standard-Workstations, ein paar Server)
- macOS in Marketing, Design, Engineering, manchmal in der Geschäftsleitung
- Linux bei CI-Buildern, NAS, einzelnen Servern und Pi-IoT-Geräten
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): Bildaufnahme + System-Audio im selben Stream (System-Audio nicht im Dienst-Modus)
- Secure Enclave für die Bindung der Host-Anmeldung
- 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: werden von aktuellen WinDesk-Versionen nicht unterstützt; nötig ist Apple Silicon (M1 oder neuer).
- 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 für die Bindung der Host-Anmeldung (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.
Raspberry Pi 4/5
Was geht:
- arm64-.deb für Pi OS Bookworm 64-bit
- Setups für Maker, IoT, Education-Labs (mit grafischer Sitzung)
Was klemmt:
- Pi 4 mit 1 GB RAM ist zu klein → mind. 2 GB empfohlen
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, SHA-256-Prüfsumme |
| Fedora/RHEL x64 | ✅ Produktiv | .rpm, SHA-256-Prüfsumme |
| Raspberry Pi 4/5 (arm64) | ✅ Produktiv | .deb arm64 |
| Intel-Mac (x64) | Nicht unterstützt | Kein aktuelles Releasepaket |
Cross-Platform-Konsistenz: gleiche Bedienung, gleiche Audit-Logs, ein Account.
Praktische Empfehlung
Wenn du eine gemischte Flotte hast:
- Test mit dem Free-Plan auf jeder Plattform. 2 Stunden reicht zum Verifizieren, dass die Bildaufnahme + Eingabe funktionieren.
- Special-Setups dokumentieren. Pi als Dienst? 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).