Montagmorgen war AutoBrew auf Version 2.4. Mittwochabend war v2.5.0 live — und bevor die Woche zu Ende ging, hatte ich schon v2.5.1 und v2.5.2 hinterhergeschickt. Drei Releases in fünf Tagen klingt nach Chaos, war aber genau das Gegenteil: eine Feature-Welle, ein Layout-Bug der sofort gefixed werden musste, und eine Aufräumaktion die ich schon länger vor mir hergeschoben hatte. Das ist die ehrliche Erzählung davon, was diese Woche in meiner macOS-App-Entwicklung passiert ist.
AutoBrew v2.5 — was sich für Nutzer ändert
Retry nach fehlgeschlagenem Upgrade
Das war das Feature, das ich am dringendsten wollte. Bisher galt: ein Homebrew-Upgrade schlägt fehl, AutoBrew schreibt einen Fehlereintrag, fertig. Der Nutzer musste selbst entscheiden, wann er es nochmal versucht. Das ist für eine App, die im Hintergrund läuft und automatisch aktualisieren soll, grundsätzlich falsch.
v2.5 hat jetzt eine Retry-Logik mit gestaffeltem Backoff: nach einem fehlgeschlagenen Upgrade versucht AutoBrew es nach einer Stunde nochmal, dann nach vier Stunden, dann nach zwölf. Das klingt simpel, war in der Umsetzung aber fiddly. Der Retry-Zustand muss über App-Neustarts hinweg erhalten bleiben — ein fehlgeschlagenes Upgrade um 23 Uhr darf nicht vergessen werden, weil der Nutzer den Mac kurz schläft. Ich speichere den Zustand jetzt persistent pro Cask-Identifier, und die Retry-Logik arbeitet sich beim nächsten App-Start zuerst durch die offene Queue, bevor neue Upgrades angestoßen werden.
Disk-Pressure-Awareness bei Snapshots
Die Snapshot-Engine aus v2.4 hatte einen blinden Fleck: sie hat immer versucht, vor jedem Upgrade einen Snapshot anzulegen — auch dann, wenn kaum noch Speicher frei war. Das konnte auf vollen Laptops dazu führen, dass der Snapshot selbst das System an den Rand brachte.
v2.5 prüft jetzt den freien Speicherplatz auf dem Home-Verzeichnis-Volume, bevor ein Snapshot angelegt wird. Liegt der freie Platz unter dem konfigurierten Schwellwert — Standard 10 GiB — wird der Snapshot für dieses Cask übersprungen und der Nutzer bekommt eine Benachrichtigung mit dem Grund. Das Upgrade selbst läuft trotzdem durch; in der Update-History-Ansicht ist der Rollback-Button für diesen einen Eintrag deaktiviert, mit einem Hinweis warum. Der Schwellwert ist konfigurierbar — wem 10 GiB zu konservativ ist, kann ihn runtersetzen.
Das hat mir gut gefallen. Die Lösung ist konservativ, transparent und lässt dem Nutzer die Kontrolle. Kein stilles Versagen, kein aggressives Blockieren.
Widget mit Run-Now-Aktion
Das Large-Family-Widget zeigt jetzt einen direkten “Jetzt ausführen”-Link, der einen manuellen Upgrade-Durchlauf anstößt. Klingt nach einem kleinen Detail — ist aber die erste Stelle in AutoBrew, wo etwas außerhalb des Menü-Bar-Popups echte Interaktivität hat. Technisch läuft das über das bestehende URL-Scheme, das ich in v2.4 eingeführt hatte; das Widget feuert intern dieselbe Route wie das CLI. Das hat mich weniger als eine Stunde gekostet und war letztlich das sauberste Argument dafür, das URL-Scheme damals sauber zu abstrahieren.
Zwei Patches und eine Aufräumaktion
v2.5.1 — der Collections-Layout-Bug
v2.5.0 war keine drei Stunden live, da hatte ich den ersten Bug-Report. Die Collections-Ansicht im BrewStore hat auf schmalen Fensterbereiten eine zweite, verschachtelte Sidebar gerendert — die innere Liste wurde auf wenige Pixel gequetscht, der Platzhalter-Text abgeschnitten. Das sah aus wie ein früher Beta-Build.
Das Problem: ich hatte dort eine NavigationSplitView eingebettet, wo ein flaches HStack-Layout völlig gereicht hätte. SwiftUI ist bei verschachtelten NavigationSplitView-Instanzen manchmal gnädig — hier war es das nicht. Der Fix in v2.5.1 war ein zwei-Minuten-Tausch, das Erkennen des Problems hat länger gedauert. Genau der Typ Bug, den man erst sieht, wenn echte Nutzer eine Fenstergröße benutzen, die man im Simulator nie getestet hat.
v2.5.2 — drei tote Symbole entfernt
v2.5.2 ist reine Housekeeping. In der Codebasis hatten sich drei Symbole angesammelt, die keiner mehr aufgerufen hat: AppLogger (alle Consumer instantiieren Logger(subsystem:category:) direkt, die Wrapper-Klasse war überflüssig), der Severity.other-Enum-Case in DoctorReport (nie zugewiesen, nie gematcht), und zwei Properties in RestoreWizardStore — sourceURL und restoreList — die zwar beim Bundle-Laden beschrieben, aber nie gelesen wurden.
Tote Code ist in Swift besonders ärgerlich, weil der Compiler einen nicht immer warnt — write-only Properties sind syntaktisch völlig valide. Ich habe mir angewöhnt, vor jedem Minor-Release einmal durch die “Find Call Hierarchy”-Funktion in Xcode zu gehen und alles ohne Aufrufer zu löschen. Das bleibt kein großes Feature, aber es hält die Codebasis lesbar.
Signing-Bereinigung auf CI
Parallel zu den Releases habe ich die CI-Pipeline aufgeräumt. Anfang der Woche hatte ich noch einen keychain-password-Secret in den GitHub Actions, der sich mit den Secrets von match überschnitten hat — seit match v1.3.0 deckt MATCH_PASSWORD das ab, der separate Wert war redundant und hat gelegentlich zu widersprüchlichen Keychain-Zuständen auf dem Runner geführt.
Außerdem habe ich kurz versucht, die Pipeline über automatic signing laufen zu lassen — und das dann wieder rückgängig gemacht. Automatic signing und Provisioning Profiles für Helper-Tools vertragen sich in Xcode nicht so einfach wie in der Dokumentation suggeriert. Ich bin zurück auf Manual+Profile gegangen. Die Versuchung, das zu vereinfachen, ist groß — aber es funktioniert jetzt verlässlich, und das ist mehr wert als eine elegantere YAML-Datei.
Was das für eine eigene App bedeutet
Wenn du überlegst, eine macOS-App entwickeln zu lassen, ist AutoBrew ein gutes Beispiel dafür, wie ein Solo-Projekt über mehrere Monate reift. Nicht jede Woche ist eine große Feature-Welle — manchmal ist der Wert ein Layout-Bug, der sofort gefixt wird, oder drei tote Zeilen Code weniger. Verlässlichkeit entsteht durch diese kleinen Schnitte genauso wie durch neue Features. Wenn dich interessiert, wie so ein Entwicklungsprozess für dein Projekt aussehen würde, schau auf /services rein.
Die aktuellen Release-Notes zu v2.5.0 bis v2.5.2 gibt es direkt auf der AutoBrew-Seite auf GitHub.