Xcode 8.3 intègre le support de Swift 3.1
Dans la foulée du tombereau de mises à jour de la soirée, Apple propose aussi la version 8.3 de Xcode. L’environnement de développement pour toutes les plateformes du constructeur inclut Swift 3.1 ainsi que les SDK pour iOS 10.3, watchOS 3.2, tvOS 10.2 et macOS 10.12.
Parmi les autres nouveautés, Xcode offre désormais le support de Siri dans le simulateur iOS, une interface revue pour la gestion des certificats et des profils, ainsi que des améliorations pour la prise en charge du débuggueur des apps Messages ainsi qu’une plus grande rapidité dans les gros projets mêlant Swift et Objective-C.
Avant, on pouvait utiliser la dernière version de Xcode, sans avoir obligatoirement la dernière version majeure de Mac OS X, mais ça c'était avant...
Oui, bon... en même temps Jean-Jacques, que XCode soit devenu un désastre, c'est pas nouveau.
Pour moi le cauchemar a commencé avec la version 4.
Mais est-ce vraiment un problème ?
Je veux dire, qu'Apple nous force à utiliser un IDE de moins en moins ergonomique, de plus en plus lent et de moins en moins productif au fur et à mesure des versions?
On n'est pas OBLIGE d'utiliser la dernière version.
Pas plus que celle de l'OS, d'ailleurs.
On n'est pas du tout non plus obligé d'utiliser les dernières API ou le dernier langage. Surtout à ce stade.
Pour ma part, je code ~80% avec XCode 3.2.6.
Le reste du temps, je vérifie que tout se passe bien avec toutes les tailles de device avec XCode 6, sous Mavericks (c'est encore fréquentable)
Et puis, au tout dernier moment, je démarre sous El Capitan, je lance une petite session avec XCode 8.2.1, analyse statique, vérifications sur des devices, tout baigne, une petite archive en mode "distribution", envoi à l'ApStore avec ApplicationLoader, et c'est tout.
Ma fréquentation de ce genre de programme fâcheux se limite donc à quelques minutes par semaines.
Ouf.
Bien entendu mon commentaire va encore susciter les cris de perroquets de hordes de developpeurs attirés par la nouveauté comme des mouches par de la bouse.
Et c'est tant mieux pour eux : s'ils aiment se faire chier.
Moi, tout ce qui m'intéresse, c'est ce qui sort à la fin du mois des ventes de mes apps. Point.
Et surtout que je n'y passe pas ma vie.
Pour ceux que ça intéresse, voici tout de même quelques avis pour le moins tranchés à propos d'XCode 8... Et c'est pas dur de trouver des plaintes à ce propos, ce serait plutôt le contraire.
D'ailleurs, n'était-ce pas la semaine dernière qu'on parlait déjà d'un certain Swift avec XCode 8 qui apportait aux développeurs de LinkedIn la joie de devoir aller faire un footing pendant que leur app pour iOS compile gentiment pendant 10 minutes ?
Je vous laisse lire :
https://www.reddit.com/r/iOSProgramming/comments/54r9ro/is_xcode_8_the_worst_release_in_recent_memory_or/
@pecos
J'aime bien les prises de position comme ça : franches et justifiées.
@pecos
Ce que tu fais n'est pas plus lent que d'utiliser xcode 8 ?
Moi j'utilise xcode (qui est mon outil de travail quotidien) depuis la v3 et franchement je le trouve euuh correct (par rapport à eclipse et compagnie)
Mes plus gros problem c'est le temps de compilation de swift, l'autocompletion et le raccourci pour aller à la declaration d'une fonction swift (le cmd+click)
@redmak : ouais, la comparaison avec Eclipse est évidemment à l'avantage d'XCode 8... y a pas photo.
mais évidemment que je gagne du temps : comme je code pas mal à l'ancienne (beaucoup de C) et que je n'ai pas du tout besoin d'APIs plus récentes que celles d'iOS 4.3, il est évident que j'ai tout intérêt à développer mes apps sur le système le plus rapide que j'ai (Snow) avec l'IDE le plus rapide et le moins buggué (XCode 3.2.6) et à le compiler, pour la phase de développement, avec un vieux LLVM GCC 4.2 qui va à la vitesse de l'éclair.
Toutes mes apps mettent moins de 4 secondes à compiler et envoyer au simulateur, après avoir fait un "clean all target".
Et pour les compilations "ordinaires", c'est juste instantané.
Là, on peut bosser.
A ce jeu là, XCode 6 sous Mavericks n'est pas mal non plus, c'est - presque - aussi rapide que le 3.2.6.
Par contre XCode 8, c'est un désastre : même en compilation ordinaire, avec des caches, il met à chaque fois au moins 10 secondes à envoyer la build au simulateur.
Je ne comprends même pas comment on peut *supporter* tant de médiocrité, en tant que dev.
Maintenant, ça met quoi à redémarrer l'iMac d'un OS à l'autre avec un bon SSD ?
10 secondes.
Et je vous rappelle que vous pouvez, dans un projet XCode, créer autant de configurations que nécessaire : une armV6/armV7 pour XCode 3, une arm64 pour XCode 6/8 et ça roule.
Et en plus les réglages pour XCode 3 n'interfèrent pas avec ceux des versions récentes.
Mais parlons en des dernières versions d'XCode : coloration syntaxique déficiente quand elle fonctionne, autocomplétion soit brutale, soit nulle (même pas capable de compléter les #import), interface builder innommable et même pas capable d'afficher en haute résolution, animations inutiles et qui transforment l'interface en guimauve, raccourcis clavier inefficaces (cmd-E/Cmd-G pour rechercher le même terme, quelle bêtise !), et je ne parle pas des dernières nouveautés : autolayout à fuir absolument à moins d'être maso.
Ah oui, le plus drôle sur XCode 8 : si j'"invente" une property qui n'existe pas (par exemple maView.tartempion) il la colore comme une vraie property et on s'aperçoit de l'erreur uniquement quand on compile. Si c'est ça, une coloration syntaxique efficace, autant mettre tout le code en noir, ça ira plus vite.
C'est pathétique.
Surtout quand on se sert de XCode 3 et qu'on sait ce que c'est, un IDE stable, qui fait le job et qui va très vite dans tous les secteurs.
Finalement, le seul point positif de tout ça, c'est que, malgré ses lenteurs et sont ergonomie douteuse, XCode 8 fonctionne pour générer mes builds finales et que j'arrive à envoyer sans problème ces builds à l'AppStore.
Pour l'instant : apparemment c'est pas le cas pour tout le monde, je lisais l'autre jour sur reddit "Apple, with XCode8, you killed my company !"
Bon, j'arrête là, le boulot n'avance pas.
@ pecos : « raccourcis clavier inefficaces (cmd-E/Cmd-G pour rechercher le même terme, quelle bêtise !) »
⌘+E et ⌘+G, ce sont les raccourcis standard pour la recherche dans toutes les applications pour Mac. Que leur reproches-tu ? C’est au contraire une très bonne chose de voir Xcode utiliser les mêmes raccourcis que les autres applications.
(Mais à part ça, moi aussi je préférais avoir un Xcode et un Interface Builder séparés et exploitant pleinement un OS conçu pour le multi-fenêtrage, plutôt qu’un machin adoptant une approche mono-fenêtre-fourre-tout à la Windows.)
@BeePotato
Ce ne serait pas plutôt cmd-F pour rechercher et cmd-G pour remplacer?
«On n'est pas OBLIGE d'utiliser la dernière version.
Pas plus que celle de l'OS, d'ailleurs.»
C'est pourtant ce que Apple veut faire croire et qu'il s'acharne a rendre de plus en plus complexe a eviter.
Et puis ça depend du projet: si tu cibles l'utilisation de fonctions proposées par l'avant derniere version de l'OS, y a besoin des API idoines et de la bonne version d'Xcode.
Et puis y a la culture de l'obsolescence programmée: Apple est champion dans le genre, mais cela contamine aussi le developpeur. Combien developpent uniquement pour un version de l'OS en tablant sur le fait que lors de la mise a jour (plus ou moins forcée, surtout avec iOS) l'utilisateur se retrouvera avec une appli inutilisable parce que pas comptablie avec l'OS nouveau, et pas moyen de revenir en arriere, donc faudra casquer pour la mise a jour... certes c'est plutot une invention de MS, mais Apple et les dev iOS ont bien appris la lecon.
Combien de dev iOS testent leurs app sur un iPhone 3GS ou 4 ?
Et pourtant la majorité des fonctions exclusives des nouvelles versions d'iOS sont accessoires...
Avec iOS 10.3 c'est l'hecatombe promise avec des vrais morceaux d'obsolescence programmée dedans.
Lorsque j'ai debuté j'ai eu la chance de tomber sur un gestionnaire de projet au sale caractere mais qui connaissait bien son boulot. Un code mal documenté et c'etait une bordee d'injures et d'humiliations devant l'equipe. On etait equipé de super machines pour developper, mais on devait faire les tests sur des vielles bécanes pourries, comme ça on etait obligé d'optimiser le code et de faire gaffe a ce que le code tourne sur plusieurs generations de l'OS.
La question aujourd'hui est de savoir a quel point Apple controle les developpeurs...
La même que RedMak, le temps de compilation, surtout dans une grosse app mélangeant Swift et Objective-C, l’autocompleetion et la coloration synthaxique qui a parfois du mal avec Swift et pour les mêmes raisons le cmd+clic qui galère car Xcode parfois ne retrouve plus ses petits avec le Swift.s
Mais c’est surtout la faute du compilateur qui mériterai une sérieuse optimisation. En témoigne l’article sur le problème de temps de compilation de l’app LinkedIn sur MacPro xD
Sinon j’ai du mal à imaginer le workflow de pecos qui passe son projet de Xcode en Xcode... Oo
Quand on pense que Xcode 3 ne fonctionne plus sur les versions récentes, et qu’il gère genre iOS 3 ou peut-être 4, des apps iOS faites avec doivent être à des années lumières d’être raccord avec les dernières version d’iOS et je sais pas comment ça se passe pour les méthodes deprecated mais bref bref bref en toute honnêteté je serais curieux de voir le workflow et voir si vraiment tout ça et un gain de temps et de performance de l’app au final car j’ai un doute sur la qualité du résultat final..
C'est vrai que le truc chiant, c'est de ne pas pouvoir ouvrir XCode 3 sous ElCapitan, il faut redémarrer.
Mais, vu ce que j'utilise des API, de toute façon, quand je me met à coder uniquement avec XCode 6/8 je code la même chose que ce que je ferais sous XCode 3.2.6.
Il faut se rappeler que la version 3.2.6 fait tourner iOS 4.3, qui intègre la principale nouveauté par rapport à ce qu'il y avait avant : les blocks.
Ce qui a été ajouté depuis est accessoire et pas indispensable, pour moi, en tous cas.
Et je n'utilise pas ARC et que je gère les retain/release à la main (question d'habitude).
Donc ça reste compatible.
Il d'ailleurs très amusant de constater qu'en 2017 on peut coder comme en 2010 et compiler avec le dernier XCode pour les derniers devices... et que ça marche parfaitement.
Pour ça, grand merci à Apple !
Donc, où est mon intérêt de se passer d'une version qui va plus vite et surtout du reste de l'environnement (l'OS) qui est bien plus efficace sur mon iMac et moins playskool et où j'ai tout mes autres softs indispensable ? (retouche d'image, SGBD, serveur, etc.)
Pour les méthodes deprecated, j'en vois passer très peu quand j'analyse avec XCode 8, et on peut les remplacer facilement, même avec du code compatible avec XCode 3.2.6.
Je dois avoir UN endroit où j'ai bricolé une classe pour rendre compatible les deux mondes, avec la méthode DrawInRect qui a pas mal évolué et dont les vieilles implémentations sont effectivement deprecated.
@pecos
Si tu développe principalement en C, ok mais après vaux mieux utiliser xcodebuild si tu déteste xcode 8..
Je crois comprendre que tu déteste soit autolayout soit interface builder avec autolayout, mois perso j'utilise un macbook pro mi-2012 entré de gamme, un macbook pro 2017 et un imac 2015 et tt fonctionne bien (bien sure il y a des probleme) mais ce tour de passe passe que tu fait moi je peux pas le faire.
Jai travailler sur un projet VOIP pendant 3 ans avec la lib oSIP et d'autres lib d'encodage audio qui sont tous en C et je restait satisfait d'xcode (ou du moins assez pour ne pas faire se que tu fais).
Pour la compilation swift tt le monde est d'accord pour dire que c'est lent, mais c'est normale, GCC ou CLANG on ete optimisé pendant des décennies !
Excuse moi, mais quant tu me dis que ton app prend 4 sec pour se lancer sur le simu apres un hard clean ca me laisse penser que ton app est un 'hello word' ! Je travaille sur des app qui prennent 4 min pour se compiler en mode debug !
Apres dis moi comment tu debug ? Je presume que ton code C est dans une lib static, alors si tu genere ton .a puis tu le met dans ton app c'est sure que ca prend moins de temp pour compiler ton app (et le hard reset n'a aucun effet sur le ce temp) mais tu peux pas debugé efficacement..
Je suis assez d'accord avec RedMark, à trop rechercher la performance brute on perd du temps sur d'autres choses. Il mentionne le deboggage, pour ma part c'est la mention de ARC qui m'a fait tiquer. Coder sans ARC demande d'ajouter plusieurs lignes de code supplémentaires à chaque fonction. Je l'ai fait pendant des années, j'avais aussi l'habitude, mais ça n'empêche pas que ça prenait du temps.
Alors oui on économise du temps de compilateurs mais je ne suis pas certain qu'on gagne beaucoup de temps de développeur. Car finalement, toutes ces nouvelles API que tu ne souhaites pas utiliser ont justement été ajoutées pour nous simplifier la vie et nous faire gagner du temps.
Tu as peut-être raison mais je ne peux pas m'empêcher de penser que l'utilisation d'anciennes API plus verbeuses + le jonglage entre les XCodes + le jonglage entre les OS font perdre beaucoup de temps. Est-ce autant, plus ou moins que le temps perdu à cause de XCode 8 ? Là est la question :)
Point complémentaire : j'ai récemment essayé AppCode de JetBrains et je dois dire que c'est sympa d'avoir un éditeur efficace (refactoring, complétion automatique, coloration, etc.) mais j'ai l'impression qu'il consomme encore plus de ressources que XCode (c'est juste une impression, faudrait vérifier) et il passe la main à XCode pour la gestion des Storyboards.
Au final je ne m'en sers pas encore au quotidien mais je pense que je le testerai à nouveau pour être certain.
C'est tres vrai dans l'ensemble, mais au niveau des API, si les nouvelles semblent plus simples et plus puissantes, elles demandent un temps d'apprentissage et de maitrise. Un bon developpeur connaissant bien son environnement et ayant de bonnes pratiques aura ses propres lib et codes bien rodés qui lui feront gagner beaucoup de temps.
Souvent je me pose la question de savoir si l'equipe de dev chez Apple "pense" l'API avant de la developper ou si c'est un processus empirique developpé au coup par coup et qui fini par nécessiter une remise en coherence a force de ressembler a un plat de spaghetti. Bon c'est pas spécifique a Apple, mais ces derniere annees ça n'a pas l'air de s'arranger et avec Swift ça devient carrément caricatural.
Pour ma part je suis satisfait de cet outil qui fait bien le boulot que je lui demande de faire.
Ça avait été un pur dur au début avec autoLayout mais depuis un moment ça roule bien.