Zum Inhalt springen
TAA

Artikel

AutoBrew v2.5.4: Xcode 27, Pipeline und SEO

Zwei AutoBrew-Releases, ein gehärteter Build-Prozess und eine komplett überarbeitete Marketing-Website: was diese Woche in der macOS-App-Entwicklung passiert ist.

, Marcel R. G. Berger, 4 Min. Lesezeit

  • macos app entwickeln
  • autobrew
  • swift
  • build-in-public
  • swift entwickler
Teilen

Zu Beginn dieser Woche lief AutoBrew noch mit Xcode 26.6. Zum Ende der Woche ist Version 2.5.4 live, gebaut mit Xcode 27.0, und der gesamte Release-Prozess ist merklich stabiler als zuvor. Parallel dazu habe ich die Marketing-Website von theapparchitect.com von Grund auf überarbeitet. macOS-App-Entwicklung bedeutet eben nicht nur Swift-Code schreiben, sondern auch alles drumherum pflegen, das dafür sorgt, dass Nutzer die App überhaupt finden und ihr vertrauen.

AutoBrew v2.5.3 und v2.5.4: zwei Releases, eine Woche

In Version 2.5.3 habe ich den Rechtsbereich der App komplett umgebaut. Vorher gab es ein segmentiertes Steuerelement oben im Fenster, das bei langen Titeln sofort unleserlich wurde. Jetzt ist es eine Seitenleiste. Elf Dokumente stehen darin, darunter ein Sicherheitsdokument, eine Richtlinie für Updates und Support, eine Offenlegungsseite für Sicherheitslücken und der California Notice at Collection. Alle elf Dokumente sind in sämtlichen App-Sprachen übersetzt. Das klingt nach Routine, war es aber nicht. Jede Übersetzung musste im Kontext der jeweiligen Rechtslage klingen, nicht wie maschineller Output. Das hat mehr Zeit gekostet als erwartet.

Drei Fehler, die ich zu lange mitgeschleppt habe

Ebenfalls in 2.5.3 enthalten: drei Korrekturen, über die ich ehrlich gesagt nicht stolz bin, dass sie so lange im Code saßen. Erstens ignorierte die App beim Erstellen von Snapshots die Einstellung für einen externen Speicherort vollständig und schrieb immer auf das System-Volume. Zweitens wurde vor jedem Snapshot kein Timeout für den vorgelagerten Hook durchgesetzt, sodass ein hängengebliebenes Skript den gesamten Prozess blockieren konnte. Drittens kollabierte das Einstellungs-Popover unter macOS 26 auf eine einzige Zeile. Das Popover-Problem war der ärgerlichste von allen drei, weil es nur auf einer bestimmten macOS-Version auftrat und mich zwei Anläufe gekostet hat, bis ich den Layoutfehler in SwiftUI gefunden hatte.

Zusätzlich habe ich die Speicherplatzkontrolle vor einem Snapshot verbessert: Die App prüft jetzt den freien Speicher auf dem tatsächlich konfigurierten Volume, nicht mehr pauschal auf dem Boot-Volume.

Der Wechsel auf Xcode 27

Version 2.5.4 bringt keine neuen Funktionen. Sie ist der saubere Schnitt auf Xcode 27.0 als einheitlichen Toolchain für alle Channels. Bis zu dieser Woche war die Situation etwas unübersichtlich: Der Test-Channel lief auf Xcode 27.0, Beta und Release blieben auf 26.6, weil ich gewartet hatte, bis Xcode 27 den GA-Status erreichte. Das ist jetzt bereinigt. Sparkle ist auf Version 2.9.0 gepinnt, damit der Update-Mechanismus nicht stillschweigend auf eine neuere Version wechselt, ohne dass ich das kontrolliert habe.

Pipeline-Härtung gegen Lieferketten-Änderungen

Parallel zum Xcode-Umstieg habe ich die Release-Pipeline gegen externe Änderungen abgesichert. Das Problem ist bekannt: Ein Workflow, der Abhängigkeiten beim Build-Schritt frisch herunterlädt, kann morgen anders verhalten als heute, wenn sich upstream etwas ändert. Ich hatte das bisher akzeptiert. Diese Woche habe ich es nicht mehr akzeptiert und kritische Werkzeuge explizit versioniert, sodass ein unerwartetes Update keinen Release-Build beschädigen kann. Kein dramatischer Eingriff, aber einer, den ich schon länger vor mir hergeschoben hatte.

Nebenschauplatz: theapparchitect.com

Neben AutoBrew habe ich diese Woche einen größeren Umbau an der Marketing-Website abgeschlossen. Einige Punkte daraus:

Das KI-generierte Porträtfoto ist weg. Es ist durch ein echtes Foto ersetzt, quadratisch zugeschnitten, freigestellt vor einem dunklen Graphit-Hintergrund. Die alte Version sah aus wie ein Stockfoto. Gut war das nicht.

Ich habe IndexNow eingebaut. Nach jedem Deploy vergleicht ein Skript die Seiten-Hashes mit dem Live-Stand und meldet neue, geänderte oder entfernte Seiten direkt an Bing und die anderen IndexNow-Suchmaschinen. Beim ersten Versuch schlug das Melden fehl, weil das Skript zu früh auslöste, bevor die Schlüsseldatei nach dem Deploy erreichbar war. Außerdem gab es sporadische 403-Antworten, die ich mit einer Wiederholungslogik abfange. Jetzt funktioniert es zuverlässig.

Außerdem sind alte Intro-Videos aus dem Repository entfernt, die veraltete Aussagen enthielten. Das Impressum wurde auf Version 1.5.1 aktualisiert und enthält jetzt klare Angaben zur Betriebshaftpflicht und Cyber-Versicherung. Und für mehrere App-Seiten, die Google noch mit alten URLs kannte und als 404 geführt hatte, habe ich die richtigen Weiterleitungen eingerichtet.

Was das für ein App-Projekt bedeutet

Wenn Sie überlegen, eine maßgeschneiderte App entwickeln zu lassen, sieht die Arbeit selten so aus, wie man sie sich vorstellt: Xcode-Toolchains wechseln, Pipelines müssen abgesichert werden, Rechtsdokumente brauchen Pflege, und eine Marketing-Website, die vor sechs Monaten gut war, ist es heute nicht mehr zwingend. Das ist der Alltag eines laufenden Software-Projekts. Auf meiner Leistungsseite können Sie sehen, wie ich diese Arbeit für Kunden strukturiere.

Die aktuelle Version von AutoBrew steht auf der App-Seite von AutoBrew.

Teilen