Quand on a besoin de voir ce qui se passe à l’exécution du code, le débogueur est un outil formidable. Dans le cadre d'un développement iOS, on utilise le débogueur LLDB fourni avec Xcode. On met un point d’arrêt là où il semble y avoir un soucis et on peut ensuite interagir directement avec le code au moment de l’exécution. C’est un outil formidable, sauf quand il ne fonctionne plus. Et c’est exactement l’aventure qui m’est arrivée cet été : une saga pleine de péripéties qui se termine par une fin heureuse, comme on les aime.
Nous étions donc avec un client au printemps quand nous avons décidé de migrer notre code sur une version plus moderne de Xcode, en l’occurrence la version 13.4. Tout se déroulait à merveille, jusqu’à ce que la machine se grippe : le débogueur LLDB ne voulait plus débogguer une partie du code. D’après les forums des développeurs Apple, le problème datait un peu et concernait un public assez limité comme je l’expliquerai plus loin. Plutôt que de perdre un temps plus précieux que les bénéfices de Swift 5.6, nous avons choisi de repousser cette migration.
Le début de l’aventure
Tout cela ne m’a pas empêché de creuser un peu plus ce sujet fort intrigant sur mon temps personnel. J’ai donc conçu un projet de démo permettant de reproduire le problème à coup sûr en limitant la quantité de code environnant qui pourrait brouiller la résolution.
En premier lieu, pour reproduire ce problème, il faut utiliser LLDB. En effet, plutôt que de mettre un point d’arrêt, nombre de développeurs se contentent d’exécuter la commande print() un peu partout dans le code et recompilent le projet jusqu’à ce que la source du problème soit débusquée. Également, il faut que l’app en question utilise des frameworks ou bibliothèques internes ou externes (CocoaPods inclus) et que le développeur souhaite débogguer ce code. Il faut aussi que ce code soit compilé statiquement : c’est généralement un avantage en termes de performances. Enfin, cela ne concerne pas les paquets Swift qui sont la manière officielle de modulariser le code selon Apple et qui bénéficient d’un meilleur accompagnement du constructeur. En gros, sont concernés les professionnels qui sont prêts à mettre les mains dans le cambouis.
J’ai donc conçu un projet décliné selon les différents cas de figure :
- une bibliothèque statique
- un framework compilé statiquement
- un pod interne configuré pour générer un framework compilé statiquement
- un code minimal utilisant Xcode en lignes de commande pour la compilation.
En parallèle, j’ai aussi créé une déclinaison utilisant des paquets Swift afin de m’assurer que cela ne vient pas de mon code Swift.
À ce stade, tout fonctionne jusqu’à Xcode 13.2.1. Ensuite, à partir de Xcode 13.3, ça ne fonctionne plus. J’ai donc l’exemple parfait, facile à débogguer et facile à comprendre.
La WWDC22 à la rescousse
Le printemps, c’est aussi l’arrivée de la WWDC et du nouveau Xcode, une arrivée à point nommé. Et là, première surprise : tout fonctionne de nouveau avec Xcode 14. Le premier automatisme est donc de se dire que c’était un bogue de Xcode 13.3 et 13.4. Mais en même temps, Apple a publié une session intrigante sur le déboggage du débogueur. Quel paradoxe ! D’un côté, le problème disparait avec Xcode 14. De l’autre, cette session fait état du problème que j’ai rencontré et apporte — au moins en partie — la solution.
