Apple a mis en ligne la version finale de Xcode 9.2
Xcode est désormais disponible en version 9.2. Cette version prend en charge les derniers kits de développement pour toutes les plateformes d'Apple, y compris macOS 10.13.2 et watchOS 4.2, qui sont toujours en bêta.
Cette mise à jour sera sans nul doute bien accueillie par les développeurs qui l'attendaient avec impatience suite à la version finale d'iOS 11.2 samedi. Xcode est disponible gratuitement au téléchargement.
J'aurais bien aimé des correctifs pour la 9.1. Et des correctifs pour la 9.0.
Mais on aura peut-être des correctifs pour la 9.2.
Ou plus probablement une 9.3 sans correctifs.
Les notes de version font toutefois mention de nombreux correctifs et d’une amélioration des temps de compilation a l’aide d’une commande expérimentale.
En revanche, même si on a fait de la route dans le bon sens depuis Xcode 8 (surtout en ce qui concerne la stabilité de SourceKit avec Swift) je dois tout de même relancer Xcode plusieurs par jour, après avoir forcé son extinction....
@Performat
Hum... Aucun soucis avec Xcode de mon côté.
Avec la version 9 je regrette la disparition des gouttières et du repli de code.
@Performat
"je dois tout de même relancer Xcode plusieurs par jour, après avoir forcé son extinction...."
Pendant ce temps, les Visual Studio ou JetBrainz tournent la semaine entière sans être redémarrés.
@fte
Comparer le rudimentaire VS Code à la puissance et l’élégance d’Xcode est loin d’être honnête. Impossible de ne pas reconnaître que Jet Brains marque des points avec IntelliJ. En revanche, il va falloir se faire à l’interface.... à noter qu’avec un langage et une suite d’outils aussi rodés que ceux d’Objective-C, Xcode est un régal à utiliser. Swift est encore relativement jeune et les progrès d’Xcode 9, montrent la voie!
@Performat
"VS Code"
Qui parle de VS Code ? J'ai parlé de Visual Studio (sur Windows, l'original).
@julienlavergne
"La mauvaise foi réincarnée !"
Oh non. Je reconnais qu’il y a une belle marge de progression pour Xcode. Je dirais plutôt la nuance. Et aussi le respect pour le travail des équipes en charge Xcode, dont la complète réécriture entreprise avec la version 9 doit être un énorme chantier.
@Performat
"Swift est encore relativement jeune et les progrès d’Xcode 9, montrent la voie!"
Kotlin est encore plus jeune, et regarde les outils d'analyse et de refactoring d'Android Studio.
Xcode n'est ni puissant ni élégant. Il est primitif et plantogène. Et il se permet d'être plus lent et gourmand qu'un IDE en Java sur la même machine et le même projet.
@ fte : « Kotlin est encore plus jeune »
Pas vraiment, non. Leur développement a débuté à peu près au même moment (vers 2010).
« Xcode n'est ni puissant ni élégant. »
Puissant, je ne sais pas — il y manque manifestement des fonctions que tu aimerais y voir.
Mais élégant, si, je trouve que c’est bien le cas (même si je le préférais quand Interface Builder était séparé).
Bien plus élégant, en tout cas, qu’un Android Studio ou un Eclipse (pour ce dernier, tout le monde s’écriera peut-être : « forcément ! »).
« Il est primitif et plantogène. Et il se permet d'être plus lent et gourmand qu'un IDE en Java sur la même machine et le même projet. »
Ben sur ma machine, il est au contraire plus rapide et nettement moins gourmand qu’Android Studio (mon seul point de comparaison actuel, car je n’utilise pas d’autre IDE en Java en ce moment).
@BeePotato
"Pas vraiment, non. Leur développement a débuté à peu près au même moment (vers 2010)."
Je pensais à la date de livraison de la version finale. Ça me semble plus approprié, parce que le standard de qualité requis par ces deux éditeur n'est clairement pas le même et il me semble très important d'en tenir compte.
"Puissant, je ne sais pas — il y manque manifestement des fonctions que tu aimerais y voir."
Refactoring. Nul. Navigation symbolique. Nul. Trouver toutes les utilisations d'une fonction ? Nope... Source control, je suppose que ça pourrait être pire. Peu probable, mais qui suis-je pour me plaindre ?
"Mais élégant"
Il y a quelques points d'organisation de projet qui laissent à désirer, côté élégance. Gestion des caches et autres intermédiaires, ça manque aussi quelque peu d'élégance. Le mode plein écran est très élégant. Tant qu'on ne n'utilise pas. L'intégr... L'absence d'intégration du simulateur et les options de config hard/soft, pas élégant.
"Ben sur ma machine, il est au contraire plus rapide et nettement moins gourmand qu’Android Studio"
Je précisais même projet. AppCode botte le cul d'Xcode. L'édition est substantiellement plus rapide, l'autocompletion beaucoup plus efficace même lorsqu'extraordiairement Xcode n'est pas en train de reindexer son cheni... Swift. Même projet. Xcode vs AppCode.
@fte
"Le mode plein écran est très élégant. Tant qu'on ne n'utilise pas. L'intégr... L'absence d'intégration du simulateur et les options de config hard/soft, pas élégant."
Un support du simulateur en plein écran semble être en préparation. Voici comment l’activer: https://medium.com/flawless-app-stories/simulator-on-steroids-c12774ca6b
@fte
À propos du réusinage de code :
J'imagine que tu veux parler également de la possibilité évoquée lors d'une Keynote que seul soit distribué le code de l'application correspondant à la plateforme.
Ce qui permettrait, en théorie que chaque iPhone/iPad en fonction de sa version et de la version d'iOS, reçoive un code spécifique le concernant ?
Si tel n'était pas le cas, cela expliquerait pourquoi un bon nombre d'applications on de gros disfonctionnements (et des gros freeze d'interface) pour par exemple l'iPhone 6 sous iOS 10 avec les mises à jours pour l'iPhone X sous iOS 11.
Pourrait-on avancer alors qu'Apple ne respecte pas ses engagements en déploiement différentiel, si le terme te convient ?
Tout en gardant à l'esprit la responsabilité dû aux développeurs sur ses propres méthodes de réusinage en vu d'une distrib' différentiée lors de dèv. cross-plateforme échappant pour une part à Apple … hum
Tous ça pour en arriver au constat qu'Apple n'a pas l'expertise pour permettre le développement de pilotage automatique, ce qui fait un peu peur quant à iOS qui se doit d'être un système avant tout temps réel.
@ fte : « Je pensais à la date de livraison de la version finale. Ça me semble plus approprié, parce que le standard de qualité requis par ces deux éditeur n'est clairement pas le même et il me semble très important d'en tenir compte. »
Ben justement, puisque ces deux éditeurs ont adopté des stratégies (plutôt que de parler de standard de qualité) différentes pour le passage en opensource de leurs langages et pour ce qui est de décider quelle version allait être étiquetée 1.0 (et non « finale »), il est bien plus approprié de comparer les dates de début de développement.
« Refactoring. Nul. »
On dira plutôt « incomplet », ce qui fait nettement moins subjectif et évite de donner l’impression qu’il est inexistant.
« Navigation symbolique. Nul. »
Même remarque.
« Trouver toutes les utilisations d'une fonction ? Nope... »
??
C’est pourtant bien quelque chose qui est disponible dans Xcode. Je ne comprends pas le sens de ta remarque, du coup.
Source control, je suppose que ça pourrait être pire. Peu probable, mais qui suis-je pour me plaindre ?
« Il y a quelques points d'organisation de projet qui laissent à désirer, côté élégance. »
Je dois préciser que je pensais uniquement à l’élégance en termes d’interface utilisateur.
Je n’arrive pas à me faire à l’interface des IDE de JetBrains. C’est bien trop fouillis à mon goût, avec des onglets de tous les côtés — trop javaesque pour moi, j’imagine.
« Je précisais même projet. »
J’ai bien lu ça. Mais n’utilisant pas AppCode, je ne pouvais pas faire une comparaison strictement sur le même projet.
Cependant, ma comparaison portait sur un projet au code partagé à 99 % entre les deux IDE (un gros paquet de C++), ce qui se rapprochait à mon avis suffisamment de ton critère pour être intéressant.
Après, attention : je ne suis pas en train d’affirmer que Xcode est parfait et qu’un truc comme AppCode n’a pas d’énormes qualités. J’apportais juste un autre point de vue sur Xcode pour nuancer ton jugement si catégorique.
@BeePotato
"« Refactoring. Nul. »
On dira plutôt « incomplet », ce qui fait nettement moins subjectif et évite de donner l’impression qu’il est inexistant."
Je n'essaie pas de donner l'impression qu'il est inexistant. Je ne nie pas son existence. Au contraire, je souligne totalement et incontestablement son existence. En précisant qu'il est nul. J'aurais pu dire nul à chier.
Tiens. Exemple.
Une méthode d'instance. Je veux enlever un argument. Click click AppCode, il mouline deux sec, me liste tous les usages de *cette* méthode (et pas une autre méthode nommée pareil mais dans une autre classe) et me propose un remplacement en bloc ou sélectif.
Mieux. Autre exemple. Toujours une méthode d'instance. Je veux ajouter un argument. Il me demande quelle valeur par défaut y mettre. Idem pour la suite. Après, ça compile directe.
Xcode est une incapable de trouver la méthode d'instance correcte si plusieurs ont le même nom dans des classes différentes. Simplement renommer résultera très souvent en un code incompilable qu'il faudra se palucher à la mano.
Xcode est infoutu d'ajouter un argument et que le code reste compilable.
Nul à chier.
Moi de même, je dois souvent forcer le redémarrage de Xcode plusieurs fois par jour. (Meme problème pour mes collègues, entre de l’Indexahe qui n’en fini plus, problème de simulateur, scrolling qui ne fonctionne plus... et j’en passe)
Xcode est le logiciel le plus plantogène de l’histoire juste après Windows 98. Un calvaire, un chemin de croix. Xcode est une honte.
@inumerix
"Xcode est une honte."
Ben dis donc...