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

Depuis le début du mois, les développeurs Mac OS et iOS disposent d'une nouvelle et quatrième version d'Xcode, leur environnement de création d'applications. Un logiciel disponible, c'était d'ailleurs une surprise, en téléchargement sur le Mac App Store [4.0 - 3,99€]. Cette version intégrant pas mal de changements, ne serait-ce que dans son interface, nous avons demandé leur opinion à quatre développeurs

[MàJ] : les remarques d'un cinquième développeur, Alexandre Bournier, ont été ajoutées après la première publication de l'article.

Ils racontent, en détail, leur expérience du nouvel Xcode. Il se dégage de ces témoignages qu'Apple a apporté des changements appréciables et utiles. Mais ils obligent à revoir quelques habitudes et il faut aussi compter avec des manques de finitions ça et là. Il est conseillé de se plonger dans Xcode 4 puisque l'avenir passe par lui, mais il n'est pas inutile de conserver une copie de la version 3 à portée de souris…

MacGeneration : Nouvelle interface, intégration d'Interface Builder, de Git, est-ce que cela rend le travail effectivement plus pratique comme le prétend Apple ?

Raphael Sebbe est l'un des co-fondateur de l'éditeur Creaceed : “Ma première réaction face à Xcode 4 a été fort négative, car cela change considérablement les habitudes établies depuis plus de cinq ans. Mais passé ce cap difficile qui demande un effort certain, c'est plutôt positif. Pour le nouveau développeur, mieux vaut s'intéresser directement à cette nouvelle version.


La nouvelle interface est de manière générale plus propre, mieux pensée. C'est un progrès si l'on accepte de revoir ses habitudes. Par contre, de nombreux détails d'utilisation - raccourcis clavier, mécanismes automatiques - ont changé ou disparu. Certaines lenteurs sont aussi gênantes, et je suis sur un Mac Pro 8 coeurs de dernière génération. Je dirais qu'Xcode 4 est à Xcode 3 ce que les voitures actuelles sont aux voitures d'il y a dix ans: c'est propre et ça marche bien, mais quand quelque chose ne fonctionne pas, c'est difficile de comprendre le problème ou de le réparer.

L'accès aux fichiers est simplifié, il y a la possibilité d'ouverture rapide en donnant quelques lettres du nom (Open Quickly…) à la manière de TextMate, ou alors directement d'afficher uniquement des sous graphes de l'explorateur de fichiers. C'est bien foutu. De même, une fonction que je demande depuis quelques années - l'accès aux fichiers récemment édités - a été ajoutée (elle était dans Project Builder il y a 10 ans, mais avait disparu d'Xcode). Toutes ces choses contribuent à une meilleure productivité pour le développeur.

La gestion des sous-projets est bien pensée. Les sous projets permettent de réutiliser un même code dans plusieurs applications (sous forme d'une librairie ou d'un framework). Dans Xcode 3, il fallait ouvrir les sous projets pour y travailler, maintenant ils sont directement accessibles depuis le projet principal, y compris les réglages, les sources, etc. C'est à nouveau un gain en productivité appréciable.

Apple définit aussi le concept de Scheme - à cheval entre un Build Style et une Target - qui symbolise l'intention du développeur. Par exemple : je compile mon application dans le but de la debugger. Ce concept est nouveau, j'ai du mal à en évaluer la portée à ce stade.

La complétion (le fait qu'Xcode puisse aider le développeur à taper le code en complétant les mots) est maintenant basée sur l'analyse du code de LLVM, alors qu'avant il s'agissait plutôt de règles générales. Cela signifie qu'elle est beaucoup plus précise qu'avant, et en particulier sur les sources en C++ (avant cela ne marchait vraiment pas bien). Xcode peut même suggérer des corrections s'il trouve un bug dans le code. D'autre part, l'outil de refactoring est également plus puissant pour les mêmes raisons. Changer le nom d'une variable ou d'une classe devient enfantin, Xcode se charge de tout (renommage des fichiers, des dépendances, etc.) avec une prévisualisation des changements qu'il compte effectuer.


L'intégration d'Interface Builder est une bonne chose. Avoir deux applications distinctes était déroutant pour les nouveaux venus en développement Mac/iOS. Une application unique, Xcode, permet une meilleure interaction entre le code source et les interfaces. Par exemple, le changement de nom d'une classe est propagé dans les xibs (c'était manuel et fastidieux dans Xcode 3/Interface Builder). L'édition de xib dans Xcode est lente cependant, j'espère que cela s'améliorera. Et il reste un problème majeur: il n'y a pas de support pour les plug-ins Interface Builder, or, des plug-ins comme BGHUDAppKit ou BWToolkit sont utilisés par beaucoup de développeurs (boutons pour fenêtres noires, non fournis par Apple, ou autres éléments d'interface non habituels). 

La navigation dans la documentation est très lente, ce point devra être revu (ndr, lire aussi Ingredients 1.0 : une fenêtre sur la doc de Cocoa). Apple a également fait machine arrière sur le multifenêtre. Ils comptaient au début interdire l'ouverture de plusieurs fenêtres sur les sources d'un même projet. Or cette fonction est utilisée par beaucoup de développeurs, et ils ont écouté (il a fallu des centaines de plaintes, je suppose…). De manière générale, lorsque certains dysfonctionnements ou erreurs de design sont constatés, c'est très difficile de se faire entendre chez Apple, ils répondent quelque chose du genre "C'est conçu pour fonctionner comme cela".

A propos du support de Git, je pense qu'Apple s'est trompée en le choisissant à la place de Mercurial. Git et Mercurial ont des concepts très similaires, mais Mercurial est plus simple et élégant à l'utilisation, a une architecture moderne (objets), est extensible, et fonctionne bien sur la majorité des OS. Git est plus populaire grâce à Github (service web de collaboration très bien fait) et Linus Torvalds qui en fait la pub, et il est plus bas-niveau. Le couple Mercurial/Git me fait penser au couple Mac/PC, et Apple a choisi le PC ici. Je n'utilise pas le support de Git dans Xcode. J'espère qu'Apple ouvrira la possibilité d'avoir des plug-ins pour les outils de versioning, mais cela reste peu probable.”


Florent Morin est avant tout développeur iOS indépendant, il a créé la société KaeliSoft : “L'intégration d'Interface Builder est réellement très pratique. On fait rapidement le lien entre le code et l'interface, et une bonne partie du code est générée automatiquement. De même, l'accès au code via une représentation visuelle des objets et méthodes est très efficace. On a tout de suite une visibilité sur l'ensemble du projet d'un point de vue code et non d'un point de vue fichiers. C'est très appréciable.


La documentation est complètement intégrée dans le code. En clair, dans 90% des cas, il n'est pas nécessaire de jongler entre les deux. L'autocomplétion a été également améliorée et c'est plutôt efficace. Autre point essentiel : nous n'avons plus besoin de compiler le code pour que le compilateur envoie des avertissements ou des messages d'erreurs. Tout est fait au fur et à mesure de la saisie et c'est un gain de temps considérable.

Le code peut même parfois être corrigé tout seul en cas de grosses erreurs. C'est anecdotique, mais ça peut parfois aider. On peut également intégrer des "snippets". En gros, il s'agit de portions de code réutilisables. On peut en créer aisément ou utiliser ceux fournis par Apple. Par exemple, on glisse-dépose une portion de code permettant d'accéder à la base de données : il n'y a plus qu'à adapter.

Pour la partie gestion des versions, tout est très bien intégré. En gros, on a une sorte de Time Machine qui permet de faire remonter en parallèle 2 versions d'un même code. Les différences sont ensuite mises en avant visuellement. C'est assez agréable et plutôt efficace. Ce qui est également intéressant, c'est le fait que Git soit enfin pleinement intégré : on commence à le voir un peu partout.

Seul bémol au niveau de l'interface : il faut un grand écran.”


Louka Desroziers est développeur iOS dans une SSII, à titre personnel (PixiApps) il est l'auteur du shareware Ecoute, un compagnon d'iTunes : “L'interface est très déroutante…le fait surtout d'avoir Interface Builder dans la même application. Mais à force de l'utiliser, on s'y habitue et on trouve ça beaucoup plus pratique. L'intégration des Snippets est assez sympa. On a rapidement accès à des portions de code le plus souvent utilisées.


Honnêtement je n'ai jamais utilisé Git. Je me contente d'utiliser SVN des repo locaux (pour tout dire, sur un disque dur externe) étant donné que je suis le seul développeur chez PixiApps. En revanche, chez mon employeur, nous travaillons avec Perforce actuellement. Et malheureusement, Apple a retiré le support de cet outil dans Xcode 4. Nous devons donc rester sous la version 3.x pour le moment.”


Florent Pillet est également développeur indépendant, il a connu l'avant Mac OS X, Palm OS ou encore Windows Mobile : “L'intégration d'Interface Builder (IB) est déroutante au début, mais on s'y fait assez rapidement. C'est une grosse transition pour beaucoup de monde. Ça vient compléter l'intégration d'IB avec Xcode, qui était déjà à l'oeuvre dans Xcode 3.2 (IB et Xcode se "parlent" en permanence, IB étant tenu au courant des changements qu'on fait dans le code). Apple a ajouté des outils assez puissants qui poussent encore l'intégration IB / Xcode, notamment par la possibilité de connecter directement des éléments d'interface avec du code, simplement par glisser-déposer entre les deux (ce n'est pas quelque chose que j'ai encore utilisé, je l'ai vu en démo).

L'intégration avec GIT est intéressante. Je m'en sers un peu, c'est beaucoup mieux pensé que dans Xcode 3, mais pour un contrôle très fin de ce que je fais, j'utilise Tower ou GitX. Pour pas mal de développeurs, l'intégration avec GIT et SVN sera suffisante au vu de sa mise en oeuvre. Une des fonctionnalités super est de pouvoir comparer instantanément (en cliquant sur un bouton) ton code avec la dernière version "commitée". Il t'affiche côte à côte deux panneaux d'édition de source et te présente clairement les différences.”

Alexandre Bournier est également développeur indépendant sur iOS et il gère le forum spécialisé PommeDev : “L’interface tout-en-un est un plus indéniable. Cependant, il faut noter qu’il existait déjà une interface comparable sur Xcode 3.x puisque l’on pouvait faire le choix dans les préférences d’une fenêtre unique pour le code, l’arborescence, le debugger et la console de logs.

La grosse nouveauté est l’intégration d’Interface Builder dans Xcode. Personnellement, je pense que c’est un plus d’avoir tout réuni dans la même application. Exit les aller-retours entre les deux applications, et la mutitude de fenêtres dans IB (inspecteur, éléments d’interface, fenêtre des API...) qui se masquaient plus ou moins selon la taille de l’écran, surtout avec plusieurs fichiers d’interface ouverts en même temps. Ces fenêtres sont remplacées par des onglets dans la partie droite de Xcode (avec des icônes pas toujours bien compréhensibles, ce qui fait qu’on tâtonne parfois !).

Dans tous les types d’applications, le choix entre fenêtre unique et multitudes de fenêtres et palettes a toujours dû s’opérer : certains utilisateurs vont adorer, d’autres détester. Personnellement, je suis friand des interfaces à fenêtre unique. Les débutants apprécieront certainement de ne pas avoir à comprendre la logique de fonctionnement entre Xcode et IB puisque tout se fait désormais dans Xcode.

Apple a sûrement fait ce choix pour supprimer certains problèmes de synchronisation entre les deux applications (notamment lorsque l’on développait des plug-ins pour Interface Builder), mais également pour séduire encore plus de monde à la programmation pour iOS et Mac, comme les développeurs qui sont déjà habitués à des environnements de développement concurrents tout-en-un sur d’autres plateformes.

La gestion des préférences du projet lui-même, et la gestion de ses targets associés (par exemple application distribuée, version démo, version beta...etc) est beaucoup plus simple dans la fenêtre centrale. On y configure aussi les icônes, les écrans d’accueil, la compatibilité OS de l’application en cours de développement, le choix du device, etc.

Tout ceci peut désormais se faire plus facilement. Les débutants apprécieront encore de ne pas avoir à chercher dans quelle ligne de la configuration du projet se trouve ce genre de fonction. L’arborescence de gauche gagne du coup en clarté.

D’autres modules ont aussi été intégrés à la fenêtre principale, comme l’affichage du QuickHelp à droite lorsque l’on sélectionne n’importe quelle fonction ou classe (une palette flottante de moins), le rechercher/remplacer dans le projet complètement rafraîchi avec un affichage plus clair des résultats, l’affichage des erreurs et warnings ou bien encore des breakpoints du debugger : Apple a fait le choix d’user et d’abuser des onglets. Il en résulte que l’interface fait plus propre et semble plus épurée.

Mais cette interface tout-en-un a un revers de la médaille : elle prend beaucoup de place si l’on ne veut pas passer son temps à scroller, surtout lorsque l’on travaille sur les éléments d’interface de son application. Il n’est alors pas du luxe de travailler au moins en 1980x1200 pixels…”