Témoignages : Xcode 4 vu par cinq développeurs

Apple fait grand cas d'une amélioration des performances des applications compilées avec LLVM 2.0, est-ce que cela se sent ou est-ce que ça ne concernera que certaines catégories de logiciels ?


Raphael Sebbe : “C'est surtout pour des logiciels faisant du traitement sur données/images/etc, mais je n'ai pas encore pu l'expérimenter sur nos produits. Les démonstrations faites par Apple sont assez convaincantes toutefois.

Le fait qu'Apple prenne son destin en main (le compilateur, en fait) est une grande avancée. Cela leur permettra d'offrir à terme des outils de plus en plus sophistiqués pour l'analyse du code, les automatismes des outils de développement, la proposition de nouveaux langages de programmation (ou évolution des langages existants). Chose qu'ils ne pouvaient pas faire aussi bien avec une dépendance aux outils externes (GCC). GCC fait un peu office de standard depuis plus d'une vingtaine d'années. Il a rendu de nombreux services à tout le monde. Mais c'est un standard lourd, son code est difficile à comprendre et il a du mal à évoluer. 

LLVM, a contrario, utilise une approche objet, décrit clairement ses concepts, et est en même temps plus efficace (mémoire et vitesse) et facilement adaptable. Il est d'ailleurs utilisé à d'autres niveaux dans Mac OS (couches graphiques), et pas uniquement pour la compilation de code Objective-C. Son auteur, Chris Lattner, est par ailleurs très sympathique et ouvert. LLVM est open source, il risque donc de s'étendre bien au delà de l'univers Apple. C'est une révolution importante dans le monde du développement. A suivre donc. (lire aussi Apple tire le jus des processeurs).”


Florent Morin : “De manière générale, l'utilisation de tel ou tel compilateur n'a pas forcément un impact immense sur les performances des exécutables. Par contre, il est clair que le choix de LLVM est vraiment très bon pour tout ce qui nécessite de gros calculs (la sécurité par exemple, la réalité augmentée probablement). Pour ce qui est de l'immense majorité des applications, l'utilisateur ne va pas percevoir directement l'impact du changement de compilateur, car les applications iOS sont déjà très rapides en général.

Vu que l'architecture matérielle est utilisée de manière optimale, il se peut cependant qu'il y ait un impact positif au niveau de l'autonomie. Mais là encore on ne va pas doubler l'autonomie de l'iPhone ! Une chose intéressante est le choix de conserver le compilateur GCC. En effet, certains outils comme la bibliothèque Cocos2D ne sont pas encore compatible avec LLVM.”


Louka Desroziers : “le débogage est nettement plus lisible qu'auparavant, Apple ayant ajouté une présentation à la Instruments, ce qui le rend naturellement plus efficace.”



Florent Pillet : “LLVM est un grand pas en avant, mais à mon sens surtout parce que son architecture permet une intégration très poussée du compilateur à l'IDE. Par exemple, la fonction "Fix It" de Xcode 4 : tu compiles ton code, tu as fait une erreur (tu n'as pas utilisé la bonne variable par exemple), il te suggère ce que tu pourrais utiliser à la place, tu as plusieurs choix, tu choisis, il te "fixe" (corrige, ndr) le code tout seul.

LLVM est également le moteur qui permet l'analyse statique du code: il parcourt tous les chemins possibles que peut suivre ton code, et te signale ce qu'il trouve comme erreurs par ce biais (par exemple, des fuites mémoires, des variables pas initialisées dans un cas particulier, etc).

La partie performance ne concerne qu'une petite frange des développeurs qui ont besoin de tirer le maximum de perfs du processeur. Pour la majorité des développeurs, l'apport de LLVM c'est avant tout une meilleure détection des erreurs potentielles dans le code, et une meilleure intégration avec l'IDE.”


Alexandre Bournier : “La réponse est presque dans la question. Apple a fait des démonstrations dans ce sens à la dernière WWDC mais avec des exemples bien choisis… La compilation LLVM 2.0 peut donc accélérer certaines applications, ou je devrais dire certaines fonctions d’applications. Je n’ai personnellement pas fait de tests là-dessus donc je n’en dirai pas plus. En revanche, la vitesse de compilation s’est grandement améliorée avec l’utilisation de LLVM 2.0, ce qui est toujours appréciable pour tout développeur.“


Est-ce que le débogage des applications (ce qui d'une certaine manière intéresse aussi l'utilisateur final d'un logiciel…) est plus efficace ?

Raphael Sebbe : “Normalement un nouveau debugger est disponible (LLDB), mais je n'ai pas pu le faire fonctionner dans la golden master (par contre, cela marchait +/- dans les bétas). Il est censé être plus léger et efficace que GDB. Mais même avec le debugger habituel - GDB - Apple a fait un travail de simplification sur ce qui est montré au développeur pendant le debugging. Avant, des centaines de variables était affichées, il fallait naviguer pour trouver l'info intéressante. Maintenant, ce travail est pré-maché et l'utilisation en définitive est plus facile.”


Florent Morin : “L'aspect débogage est plus efficace, en effet. Le débogueur semble avoir beaucoup plus la main sur l'exécution du programme et l'interface utilisateur offre plus de souplesse.”


Florent Pillet : “Le nouveau debugger, LLDB, n'est pas encore au point, il a même été retiré de la golden master pour le développement iOS car il crashait pas mal. Au niveau debug, on est donc toujours avec GDB. Je trouve la présentation du debugger dans Xcode 4 plus claire, mais au niveau efficacité c'est la même chose : ce qui ne marchait pas bien dans Xcode 3 (par exemple, l'affichage du contenu des strings) fonctionne toujours moyennement.”


Alexandre Bournier : “Il y a une nouveauté importante: le compilateur nous indique en temps réel au cours de la frappe du code ce qui ne va pas. C’est un peu déroutant au début car il nous signale des évidences (puisqu’on n’a pas fini de taper une fonction ou une ligne…) puis on s’y fait très vite : le fait de pouvoir découvrir une erreur avant de lancer la compilation est un plus indéniable qui nous fait gagner du temps.

L’affichage de la liste des erreurs et warnings dans la partie gauche de l’interface est également pratique pour naviguer d’erreur en erreur, et de fichier en fichier.

La partie qui gère le déroulement du programme lors de la phase de «débuguage» et qui affiche les valeurs de nos objets (entre autres) est également plus claire et plus concise qu’auparavant. Avec la console juste à droite, ça devient un outil redoutablement efficace pour trouver les failles.”


Est-ce que cette version 4 est assez stable et assez mûre pour être utilisée au quotidien ou mieux vaut-il garder la 3 sous le coude ?
Raphael Sebbe : “Choix difficile. Il reste des choses pas tout à fait fonctionnelles, comme dans l'ajout de dépendances sur des sous projets. Mais cela fait environ deux ans qu'Xcode 3 n'a plus évolué, et clairement, Xcode 4 a toute l'attention d'Apple. Par conséquent il vaut mieux s'habituer rapidement à ses nouveaux concepts, car un jour, peut-être pas si lointain d'ailleurs, Xcode 3 ne permettra plus de créer des applications pour l'App Store.

Cette transition est réalisée de manière intelligente, dans le sens où les projets Xcode 4 restent compatibles avec Xcode 3. Donc, lorsque certaines opérations sont difficiles avec la nouvelle version, on peut toujours les réaliser avec Xcode 3 sur le même projet. Il n'y a pas de cloisonnement absolu entre les deux.

J'ai commencé par l'utiliser exclusivement sur le développement d'Hydra 3, et ça s'est bien passé même si je perdais parfois un peu de temps pour m'habituer aux nouvelles approches. Aujourd'hui je n'utilise plus que lui. La correction et la notification des erreurs au fur et à mesure de la frappe apportent un réel gain de productivité.“


Florent Morin : “J'ai utilisé la golden master d'XCode 4 pendant une semaine environ, pour me l'approprier. L'outil en lui-même est génial, mais ses performances sont intolérables. J'ai l'impression de travailler avec Eclipse. On va mettre ça sur le dos de la version GM, en espérant que la prochaine version soit plus rapide et exploite les fantastiques possibilités offertes par le 64-bits et Grand Central Dispatch qui ont tant été mises en avant par Apple. C'est vraiment dommage, car sinon le résultat est nickel. Je ne l'utiliserai au quotidien que lorsqu'il sera suffisamment stable pour un usage pro ou s'il arrive qu'on n'ait pas d'autre choix.

En même temps, étant développeur moi-même, je peux aisément comprendre qu'une application aussi énorme ne soit pas optimisée dès sa première version. Mais en l'état, je reste sous XCode 3, car l'énorme bénéfice offert par la version 4 est anéanti par ses piètres performances.”


Louka Desroziers : “ll m'a planté trois fois dans les mains aujourd'hui (ndr, l'interview date du 11 mars, mais la conclusion ci-après n'a pas varié depuis), sans usage intensif. Juste quand je souhaitais afficher l'inspecteur d'objets.

Outre la gestion du SVN foireuse (en tout cas dans les "commit"), Interface Builder souffre du manque de raccourcis clavier autrefois spécialement faits pour lui. Par exemple, j'utilisais cmd- et cmd+ pour rapidement re-dimensionner un label… Maintenant ce n'est plus possible. Pareil pour mettre le texte du label en gras, cmd B effectue un Build dans Xcode…

Bref, rien qu'à cause de ça, je repasse sous Xcode 3 immédiatement. À force ça devient vraiment pénible… Certes les onglets sont super pratiques, et le debugging est plus agréable, mais là ça devient lourd et contre-productif, sachant que je passe quand même plus de temps à développer qu'à debugguer.

Sinon je regrette le mode unifié… mais ayant testé Mac OS X Lion, je pense que ça peut-être assez fun à utiliser si Apple intègre le plein écran dans Xcode 4. Et niveau productivité, ça doit être tout bon par la même occasion ! J'imagine déjà un espace Xcode plein écran, et un autre avec Safari qui me permettra de feuilleter des forums en cas de besoin.”


Alexandre Bournier : “Elle est assez mûre mais plutôt instable : il m’est arrivé de planter 2 à 3 fois par jour. Cependant, Xcode crash (avec un joli message d’erreur) mais l’on n’est pas obligé de le redémarrer forcément : on peut continuer le déroulement du programme.

Cette version 4 a aussi d’autres problèmes: le debugger n’affiche pas toujours les lignes concernées par les bugs et se contente de signaler une erreur dans une page (on perd du temps à la trouver), l’auto- complétion s’endort parfois, tout comme la coloration syntaxique du code. Il arrive également de devoir attendre 5 secondes lorsque l’on déplace un groupe de fichiers dans l’arborescence du projet alors que c’était immédiat sur la version 3.x.

Je conseille cette version à tous les développeurs qui n’ont pas de projet urgent à rendre à des clients (car dans tous les cas il faudra un temps d’adaptation d’environ 1 semaine), ainsi qu’à tous les développeurs qui débarquent tout juste sur notre plateforme : autant utiliser les derniers outils mis à disposition par Apple !

Quant à ceux qui ont besoin de garder la compatibilité de leurs applications avec Mac OS 10.5, le choix est malheureusement vite fait : il faudra garder Xcode 3.x pour le moment (à moins que les choses évoluent du côté d’Apple).”


Florent Pillet : “J'utilise les deux versions. Xcode 4 a besoin de mûrir encore. Certains aspects cruciaux de l'IDE, par exemple l'indexer (qui indexe ton code et sert de fondation pour les suggestions automatiques pendant qu'on tape le code, ainsi que pour la colorisation du code) a parfois des sautes d'humeur et ne marche que partiellement pour certains projets. Sur ces projets, je suis obligé de revenir à Xcode 3, car la colorisation et les suggestions automatiques sont essentielles quand on fait du Cocoa, vu la longueur des noms de méthodes et la richesse du framework on peut perdre beaucoup de temps à chercher "à la main".

Au niveau stabilité, Xcode 4 plante encore de temps en temps, mais la plupart de ses erreurs internes sont intelligemment capturées, puis affichées et on peut les ignorer et continuer à travailler. Ce n'est pas parfait, mais ils ont fait quelque chose comme dans Chrome qui permet de ne pas avoir à relancer Xcode quand une partie de l'IDE plante.

Au niveau facilité d'utilisation, c'est une grosse transition pour tous les utilisateurs d'Xcode 3. Les automatismes changent, certaines manipulations ne se font plus de la même façon. C'est parfois un peu déroutant au départ, mais on s'habitue vite et j'apprécie la nouvelle façon de faire.

Un des nouveaux outils que j'apprécie énormément c'est la possibilité de définir ses propres raccourcis: l'IDE intègre une interface qui te permet de te créer des bouts de code "template", avec une abréviation. Quand tu la tapes, ça marche comme la complétion automatique du code - il te suggère ta template, tu fais "tab" et il te l'insère dans le code. C'est un outil qui me fait gagner beaucoup de temps.

Il y a pas mal d'autres aspects de Xcode 4 qui me plaisent, comme la nouvelle mouture de l'organizer qui synthétise la gestion des devices, du provisioning, des builds archivés et des dépôts de source.

Pour résumer, Xcode 4 est une refonte complète de l'IDE d'Apple avec une intégration poussée d'outils précédemment séparés, avec une nouvelle interface très riche qui demandera quelques efforts d'adaptation aux développeurs. Je pense que le jeu en vaut la chandelle, une fois qu'on a "compris" comment faire les choses on apprécie beaucoup le confort qu'apporte cette nouvelle IDE.”

Sur le même sujet :
- Une solution pour les problèmes d'installation de Xcode 4
- Les autres témoignages d'utilisateurs de MacGeneration (Les logiciels de virtualisation, Synchroniser sans MobileMe, les SSD, le MacBook Air 11", la décroissance sur Mac, le Magic TrackPad, iWork.com, le Mac mini server…).

Autre ressources :
- Xcode 4 mis à jour
Le forum Développement sur Mac de MacGeneration
Le forum PommeDev