Hersteller-Bloatware wird endlich optional - und diese App beweist, dass sie eigentlich nie hätte existieren müssen.
Egal, ob Sie eine neue Maus, eine Tastatur, Kopfhörer oder einen kompletten Computer kaufen - es gibt immer eine gewisse Art von Frustration. Sie öffnen die Verpackung Ihres neuesten Kaufs, schließen das Gerät an - und bevor Sie auch nur eine Funktion nutzen können, erhalten Sie die Aufforderung, eine 200 MB große App herunterzuladen - vorausgesetzt, der Hersteller hat sie nicht bereits auf Ihren Computer installiert.
Es bleibt nicht dabei, einfach nur die App herunterzuladen. Man muss außerdem ein Konto erstellen und einer Datenschutzrichtlinie zustimmen - eine Richtlinie, die genauso kompliziert ist wie ein Hypothekenvertrag. All das nur, um eine einfache Maus mit ein paar zusätzlichen programmierbaren Tasten zu kaufen. Jahrelang wurde uns eingeredet, dass solche „Überflüssigkeiten“ seitens der Hersteller notwendig seien. Diese App beweist, dass das nicht der Fall ist.
Niemand hat nach einem weiteren Geräte-Ökosystem gefragt.
Wie Hersteller einfache Peripheriegeräte zu Softwareplattformen machten
Es ist auch niemals nur eine einzige App. Eine typische Konfiguration im Jahr 2026 umfasst beispielsweise Logitech Options+ oder G Hub für die Maus, Corsair iCUE für die Tastatur, Razer Synapse für das Headset sowie Asus Aura Sync, falls Ihr Mainboard über Beleuchtung verfügt. Jede dieser Apps startet beim Hochfahren des PCs einen eigenen Hintergrunddienst. Corsair führt sogar eine offizielle Liste von Software-Programmen, die mit iCUE in Konflikt geraten - und auf dieser Liste stehen praktisch alle anderen Peripherie-Software-Programme, die man eventuell installiert hat.
Man sammelt sie alle zusammen - und ehe man sich versieht, sind bereits ein Gigabyte Speicherplatz verbraucht, noch bevor man auch nur ein einziges Browser-Fenster geöffnet hat. In Razers eigenen Foren berichten Nutzer, dass Syanpse aufgrund von Speicherlecks im Idle-Zustand fast 1 GB Speicher belegt. Logitech Options+ erzeugt laut Berichten über 126 Threads und nutzt dabei Hunderte von Ports - und das alles nur, um der Scroll-Leiste zu sagen, wie sie sich verhalten soll. Alle diese Programme starten außerdem einen kleinen, versteckten Server auf Ihrem Rechner, der darauf wartet, etwas zu tun - was er allerdings nur selten tun muss. Einzeln betrachtet scheint das nicht viel zu sein; doch wenn man sie alle kombiniert, ist der verfügbare Speicherplatz plötzlich nicht mehr nutzbar.
Warum braucht ein Treiber 500 MB RAM?
Die Electron-Apps, die vorgeben, Hardware-Dienstprogramme zu sein
Ein großer Teil der Schuld liegt bei Electron - dem Framework, das es Entwicklern ermöglicht, Web-Apps als Desktop-Software zu veröffentlichen. Native Windows-Apps verschwinden bereits seit einiger Zeit, und nahezu jede moderne App, auf die man heute stößt, verwendet dieses Framework.
Als Entwickler verstehe ich das. Man schreibt den Quellcode einmal in JavaScript und stellt ihn für alle Betriebssysteme bereit. Dadurch reduziert sich der Aufwand, getrennte Codebasen für die einzelnen Betriebssysteme zu pflegen - sowie der Bedarf an Entwicklern, die diese Codebasen erstellen und aktualisieren müssen. Der Nachteil dabei ist, dass jede Electron-Anwendung eine vollständige Kopie von Chromium mit sich bringt. Drei solcher Anwendungen zu starten, kommt im Grunde dem Ausführen von drei „versteckten“ Chrome-Browsern im Hintergrund gleich - wobei jeder Browser seine eigene Rendering-Engine besitzt, die jedoch untätig bleibt.
Abgesehen von dem hohen Speicherverbrauch dauert es länger, bis Programme geöffnet werden, da sie darauf warten, dass die Laufzeitumgebung geladen wird. Die UI-Elemente sehen und verhalten sich nicht immer wie native Steuerelemente. Systemthemen und die Skalierung funktionieren manchmal gut, manchmal nicht. Tastenkombinationen können inkonsistent sein - und mehrere eingebettete Browser gleichzeitig im Speicher laufen zu lassen, ist auch nicht gerade gut für die Akkulaufzeit Ihres Laptops.
Nicht alle Electron- oder webbasierten Apps sind schlecht. Ein klassisches Beispiel ist Visual Studio Code. Es handelt sich dabei um eine Electron-App - einen der besten Code-Editor überhaupt - und sogar die perfekte Schreib-App, die man nutzen kann. Sie ist äußerst leistungsfähig und für ihren Zweck gut optimiert. Es geht hier nicht darum zu sagen, dass Electron schlecht ist; vielmehr hat dieser Ansatz es Entwicklern erleichtert, sich weniger um die Optimierung zu kümmern.
Mac-Nutzer hatten das Nachsehen.
Begrenzte Unterstützung, überladene Tools und endlose Workarounds
Nichts davon ist gleichmäßig verteilt. Windows-Nutzer erleben eine überladene Benutzeroberfläche; macOS-Nutzer erleben eine überladene Benutzeroberfläche sowie Instabilität. Mittlerweile ist das fast schon eine Tradition.
Anfang 2026 funktionierte die Options+-App von Logitech auf macOS plötzlich nicht mehr - weil das Unternehmen vergessen hatte, ein SSL-Zertifikat zu erneuern. Bei Nutzern von macOS Ventura, Sonoma und Sequoia geriet die gesamte App in eine Endlosschleife beim Starten. Die Scrollrichtungen funktionierten nicht mehr, benutzerdefinierte Einstellungen reagierten nicht mehr - und das Update-Verfahren innerhalb der App konnte kein Update bereitstellen, da es ebenfalls an dem aktualisierten Zertifikat scheiterte.
Die Nutzer mussten die Patches manuell suchen und installieren. Windows-Nutzer waren davon hingegen überhaupt nicht betroffen. Zuvor zeigte Options+ auf macOS ein wohlbekanntes Verhalten: Es verbrauchte im Leerlauf viel CPU-Leistung, ließ dabei ansonsten leise laufende Geräte laut werden, stürzte nach bestimmten Updates alle paar Sekunden ab und zwang die Nutzer dazu, in das Terminal zu wechseln, um einen hängengebliebenen Prozess zu beenden. Die Lösung war einfach: Ein Shell-Befehl, mit dem der Agent manuell beendet werden konnte - dieser Befehl musste jedoch jedes Mal erneut ausgeführt werden.
Der Grund dafür ist struktureller Natur. macOS fügt mehrere Berechtigungsebenen hinzu - Zugriff auf Barrierefreiheitseinstellungen, Überwachung von Eingaben, vollständiger Zugriff auf die Festplatte -, um die herum diese Apps sorgfältig entwickelt werden müssen. Doch wenn man einen einzigen Codebasis schreibt, der auf verschiedenen Plattformen verwendet werden soll, werden solche Probleme nicht so gelöst, wie es nötig wäre. Das bedeutet: Alles bricht zusammen, sobald etwas schiefgeht oder ein Problem auf Serverseite auftritt. Für eine App, deren einzige Aufgabe darin besteht, im Hintergrund zu laufen, ist das eine Menge Wartungsaufwand.
So hätte die Software von Anfang an aussehen sollen.
Leichtgewichtig, nativ und auf die Hardware ausgerichtet - anstatt auf Marketing.
OpenLogi wurde Mitte 2026 als direkte Lösung für dieses Problem für macOS-Nutzer eingeführt. Es wurde in Rust programmiert - nicht in JavaScript oder Electron - und kommuniziert direkt mit Logitech-Mäusen über das HID++-Protokoll mithilfe eines Logi Bolt-Empfängers oder Bluetooth. Es gibt weder Cloud-Dienste noch Hintergrundprozesse, die um Berechtigungen kämpfen. Die Zuweisung der Tastenfunktionen wird in einer einfachen TOML-Datei auf Ihrem eigenen Rechner gespeichert.
Die App verfügt über eine übersichtliche Benutzeroberfläche, die ein interaktives Diagramm Ihrer Maus zeigt. Zudem gibt es einen klickbaren Auswahlbereich mit 37 integrierten Aktionen. Für die Skriptverwendung steht außerdem eine Befehlszeilenschnittstelle zur Verfügung. DPI-Einstellungen, Umschaltung des SmartShift-Radmodus sowie Profilverwaltung pro Anwendung - all das ist vorhanden und wird lokal verwaltet, ohne dass eine Verbindung zu Logitech erforderlich wäre - es sei denn, Sie erlauben explizit den Abruf von Gerätebildern.
Ein Blick auf eine bessere Zukunft
Optionale Software wird endlich Realität
OpenLogi ist vorerst nur für macOS verfügbar; Linux und Windows sind in der Zukunftsplanung vorgesehen. Doch gerade die Tatsache, dass die Entwicklung von OpenLogi auf macOS begonnen hat, ist das Interessante daran. Es wurde zunächst für die Plattform entwickelt, die historisch gesehen am schlechtesten unterstützt wurde - eine Plattform, auf der es besonders viele Abstürze gab und die bei der Entwicklung von Peripherie-Software am meisten vernachlässigt wurde. Selbst unter Linux gibt es Solaar - ein reifes, open-Source-Programm von Logitech, das Tastaturen, Mäuse und Empfänger problemlos verwaltet. Was OpenLogi zu diesem wachsenden Ökosystem hinzufügt, ist ein wirklich ausgereiftes, lokal ausgerichtetes Nutzererlebnis.
Die Wahrheit ist: Es hat nichts mit technischen Schwierigkeiten zu tun. Das HID++-Protokoll ist ausreichend dokumentiert, sodass unabhängige Entwickler es in ihrer Freizeit problemlos reverse-engineeren können. Das Cloud-Konto, der Electron-Wrapper sowie die komplizierte Berechtigungsstruktur des Daemons - all das war niemals eine technische Einschränkung. Es war eine Produktentscheidung. Mac-Nutzer tragen bereits am längsten die Folgen dieser Entscheidung. OpenLogi ist das erste Zeichen dafür, dass sie - und letztendlich auch wir alle - das nicht mehr tun müssen.