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…”

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