DropSlim – wie aus einer alltäglichen Notwendigkeit eine eigene Desktop App wurde
Einsatzbereich - und warum das nützlich ist
DropSlim ist kein Werkzeug für Build-Pipelines, Skripte oder automatisierte Optimierung im Entwicklungsprozess. Es ist ein manuelles Alltagswerkzeug für den einen Moment, in dem gerade jetzt ein paar Bilder kleiner werden müssen.
Typische Situationen:
- E-Mail-Anhänge - der Fotoanhang ist zu groß fürs Postfach; ein Zug auf die App, und er passt.
- Uploads - Bilder für ein Formular, ein Portal oder eine Website vorbereiten, ohne extra ein Bildprogramm zu öffnen.
- Dokumente und Präsentationen - Screenshots und Fotos verkleinern, damit die Datei nicht unnötig aufbläht.
Der Nutzen liegt genau in dieser Unaufgeregtheit: keine Einstellungen, die man verstehen muss, kein Export-Dialog, kein Konto. Man zieht die Dateien auf das Fenster, und die App erledigt den Rest - lokal, offline und ohne dass etwas hochgeladen wird. Bildkomprimierung ist eine kleine, häufige Aufgabe. Genau dafür ist ein Werkzeug, das nur das kann und dabei schnell und einfach ist, im Alltag Gold wert.
Warum überhaupt eine neue App?
Der Auslöser war zum einen der Bedarf - und zum anderen die Motivation, neue Techniken kennenzulernen. Bilder komprimieren gehört auch für uns zum Alltag - für Anhänge in E-Mails, für Uploads, für Dokumente. Genau für solche Aufgaben außerhalb des Entwicklungskontexts war über lange Zeit Image Shrinker das Werkzeug der Wahl: einfach, schnell, per Drag & Drop.
Das Problem: Image Shrinker ist nach heutigem Stand nicht mit zukünftigen macOS-Versionen auf Rechnern mit Apple-Chip kompatibel. Wer also auf einem aktuellen Mac mit Apple Silicon arbeitet, steht zukünftig eventuell ohne dieses gewohnte Werkzeug da.
Hinzu kommt: Die meisten unserer Kunden arbeiten mit Windows-Rechnern, und dort fehlt ein adäquates Tool für diese alltägliche Aufgabe bislang.
Statt auf einen Ersatz zu warten, haben wir die Gelegenheit genutzt, selbst etwas zu bauen - eine kostenfreie App, die genau diese eine Aufgabe gut erledigt: Bilder rein, kleiner raus, fertig. Ohne Account, ohne Server, ohne Umwege.
Von Electron zu Tauri
Die bislang naheliegende Wahl für eine Desktop-App mit Web-Technologien wäre Electron gewesen. Electron bringt für jede App eine komplette Chromium-Engine und eine Node.js-Laufzeit mit. Das ist bequem, führt aber zu vergleichsweise sehr großen Bundles. Wir haben uns stattdessen für Tauri entschieden.
Tauri geht einen anderen Weg:
- Native WebView statt gebündeltem Browser - Tauri nutzt die im Betriebssystem bereits vorhandene WebView-Komponente. Das spart den größten Brocken ein.
- Rust im Backend - die Kernlogik läuft in Rust statt in Node.js: speichereffizient, schnell und mit klaren Sicherheitsgrenzen zwischen Frontend und System.
- Deutlich kleinere Bundles - statt Hunderten von Megabyte landet man bei unter 15 MB.
- Natives Packaging - Tauri erzeugt direkt die plattformüblichen Formate: .dmg auf macOS, .exe-Installer auf Windows, .AppImage auf Linux.
Was das konkret bringt
Für eine App, deren einzige Aufgabe „mach dieses Bild kleiner“ lautet, ist ein 200-MB-Download sehr viel. Tauri passt hier ideal: Die Bildoptimierung selbst lassen wir ohnehin über native Bibliotheken laufen (imagequant, oxipng, zenjpeg, OXVG, gifsicle sowie WebP- und AVIF-Encoder), und Tauri liefert den schlanken Rahmen drumherum. Das Ergebnis ist eine App, die klein, schnell und offline nutzbar ist.
Das ist ausdrücklich keine Abrechnung mit Electron - im Gegenteil, Electron ist ein großartiges Werkzeug und trägt unzählige Anwendungen. Bei einer so kleinen App ist der Unterschied ehrlicherweise auch nicht wirklich entscheidend. Für uns war der Ausschlag vor allem der nette Lerneffekt, Tauri einmal in einem echten Projekt einzusetzen.
Die Hürden bei der Installation
So schlank die App technisch ist - der unangenehmste Teil hat mit der App selbst gar nichts zu tun, sondern mit den Hürden, die beide großen Desktop-Plattformen zwischen einen freien Download und den ersten Start stellen.
macOS: Gatekeeper und der Developer-Ausweis
Auf macOS sorgt Gatekeeper dafür, dass aus dem Netz geladene Apps zunächst blockiert werden. Der reguläre Weg, das zu umgehen, führt über das kostenpflichtige Apple Developer Program (99 EUR pro Jahr), inklusive Identitätsprüfung, Developer-ID-Zertifikaten, app-spezifischen Passwörtern und Notarisierung der App bei Apple.
Wir haben diese Gebühr bezahlt, damit Mac-Nutzer eine ganz normale Installation bekommen: DMG öffnen, App in den Programme-Ordner ziehen, starten - ohne Warnhinweise oder Terminal-Tricks.
Windows: SmartScreen und das Reputationsspiel
Auf Windows behandelt Microsoft Defender SmartScreen unsignierte Installer grundsätzlich als verdächtig. Der glatte Weg führt über ein kommerzielles Code-Signing-Zertifikat (rund 100 EUR pro Jahr und mehr) - und selbst dann baut sich „Reputation“ nur langsam auf und hilft kleinen Open-Source-Projekten kaum.
Diese Windows-Signierung zahlen wir bewusst nicht. Stattdessen kommt man mit zwei Klicks weiter: bei der SmartScreen-Warnung auf Weitere Informationen und dann Trotzdem ausführen. Der Installer ist sicher, solange er aus dem offiziellen Repository oder von der Projekt-Website stammt.
Warum Windows so viel Aufwand war
Dass wir die App zuerst unter macOS gebaut haben, merkten wir beim Portieren auf Windows deutlich. Die eigentliche Bildlogik war plattformunabhängig - der Ärger steckte im Detail der Windows-spezifischen Abhängigkeiten und im Packaging.
Vieles, was auf macOS „einfach da“ ist, mussten wir für Windows von Hand mitliefern: die dav1d.dll für AVIF, die Visual-C++-Runtime und ein selbst gebautes gifsicle samt seiner MinGW-DLLs. Dazu kamen Tücken beim Bundling - ein falsches Ressourcen-Muster ließ eine DLL verschwinden und die GIF-Optimierung still scheitern - und in der CI, wo der AVIF-Encoder rav1e zum Bauen erst NASM braucht.
Unterm Strich: Was auf macOS in wenigen Schritten lief, war unter Windows eine Kette aus DLLs, Pfaden, Build-Werkzeugen und CI-Anpassungen. Nichts davon spektakulär - in Summe aber recht aufwändig.
Linux ist geplant
Eine Linux-Version haben wir bereits angedacht. Dafür gibt es einen Feature-Branch (feature/linux), auf dem unsere CI eine AppImage (x86_64) baut.
Trotzdem legen wir das Ganze vorerst auf Eis - aus Zeitgründen und wegen der begrenzten Testmöglichkeiten fehlt uns die saubere Verifikation, die es vor einer echten Veröffentlichung braucht. Die Grundlagen stehen - der letzte Schliff und das breite Testen kommen, sobald die Zeit da ist.
Ein Nebeneffekt: Nachhaltigkeit
Kleinere Bilddateien bedeuten weniger Daten - beim Versand per E-Mail, beim Upload und bei jedem späteren Abruf über das Netz. Und weniger übertragene Daten heißt schlicht weniger Energie: Server, Netzwerke und Endgeräte müssen weniger bewegen und verarbeiten. Da Bilder oft den größten Teil einer Datenübertragung ausmachen, ist das Komprimieren nicht nur praktisch, sondern auch ein konkreter Beitrag zu einem ressourcenschonenderen Umgang mit Daten.
DropSlim ausprobieren
DropSlim ist kostenlos und quelloffen. Download und weitere Infos gibt es auf dropslim.app, der Quellcode liegt auf GitHub.
