Xcode 11.4 va améliorer le quotidien des développeurs
Dans la fournée de bêtas de la semaine, Apple a aussi distribué une première bêta de Xcode 11.4. La prochaine version de son outil de développement contient de nombreuses nouveautés, dont certaines sont liées à l’intégration de Swift 5.2. On fait le point rapidement sur les principaux changements à attendre dans cette mise à jour.
Des notifications dans le simulateur
Xcode est fourni avec un simulateur qui permet aux développeurs d’apps iOS, watchOS ou tvOS de tester leur travail sans avoir à installer l’app à chaque fois sur un appareil de test. Il sert aussi à tester une app sans avoir toutes les variantes de chaque matériel jamais vendu par Apple. C’est un outil très pratique, mais certaines fonctions devaient encore être testées directement sur les appareils concernés.
C’était le cas jusque-là des notifications push envoyées par un serveur distant. Le simulateur permettait de tester les notifications générées sur l’appareil lui-même, une autre option proposée aux développeurs, mais pas celles qui sont envoyées depuis un serveur. Avec Xcode 11.4, cette limite sera levée et le simulateur permettra de vérifier que tout fonctionne sans quitter son Mac :
Simulateur oblige, vous n’avez pas besoin d’un vrai serveur de push pour utiliser cette fonction. Vous pouvez simuler le serveur aussi à l’aide d’un outil en ligne de commande à utiliser dans le terminal. La fonction peut ainsi être vraiment testée avec un seul Mac, même sans connexion internet.
Swift 5.2 améliore ses messages d’erreur
Xcode 11.4 intègre aussi la première bêta de Swift 5.2, le langage de développement utilisé par Apple. L’un des objectifs annoncés par la firme pour Swift était d’améliorer le quotidien des développeurs et cela commence avec cette mise à jour.
Au programme, des messages d’erreur plus utiles, tout particulièrement si vous utilisez SwiftUI. Le framework d’interface d’Apple n’a pas encore fêté son premier anniversaire et même s’il simplifie considérablement le travail des développeurs pour créer des interfaces simples, il peut vite devenir un cauchemar dès lors que les besoins se compliquent. En particulier, ses messages d’erreur sont souvent assez obscurs et n’aident pas à comprendre ce qui ne convient pas. Swift 5.2 devrait améliorer ce point, comme en témoigne cet exemple :
Les messages d’erreur devraient ainsi être en général plus complets et plus clairs, ce qui permettra aux développeurs de comprendre plus facilement ce qui ne va pas et corriger leur code. Et toujours dans l’esprit de régler les problèmes, Xcode 11.4 propose une nouvelle option dans son inspecteur d’interface. Il est désormais possible de séparer chaque « couche » (CALayers) de l’interface, pour mieux inspecter un élément précis.
Swift 5.2 contient aussi de nouvelles fonctions pour les développeurs, qui pourront trouver une liste avec des explications sur le site Hacking with Swift.
Compilations accélérées en Swift et Objective-C
Apple avait aussi promis des progrès pour les temps de compilation du code source, une étape indispensable pour vérifier que tout fonctionne correctement. Avec Xcode 11.4, les développeurs devraient noter une réduction du temps de compilation, qu’ils utilisent toujours Objective-C ou qu’ils soient passés à Swift. Apple va continue de travailler sur ce point en préparant Swift 6, mais cette mise à jour de Xcode améliore déjà les choses sur les projets existants.
Un développeur a compilé deux projets, un dans chaque langage, sur le même Mac équipé d’un processeur huit cœurs. Avec Xcode 11.3, il fallait environ 77 secondes pour compiler les deux projets. La mise à jour baisse ce temps d’une vingtaine de secondes environ, avec un gain plus net pour Swift que pour Objective-C :
Xcode 11.4 est disponible au téléchargement depuis le site dédié aux développeurs d’Apple. Cette version nécessite pour la première fois macOS Catalina, elle ne s’installe plus sur Mojave (enfin, en tout cas pas sans bricoler).
Ah ça pour être obscures les erreurs avec SwiftUI...
Bon point !
La vraie demande des développeurs, elle a été adressée directement à Steve Jobs en pleine Keynote par quelqu’un dans le public. On attend toujours....
-https://youtu.be/yqDVtB-6jDE
@jackhal
Ils sont un peu sourd chez Apple. C’est bien connu.
@jackhal
Génial!! merci pour le partage 😅
« ce qui permettra aux développeurs de comprendre plus facilement ce qui ne va pas et corriger leur code »
Ne voulez-vous pas dire plutôt ceci ?
« ce qui permettra aux développeurs incomptétents de comprendre plus facilement ce qui ne va pas et corriger leur code »
Pourquoi incompétents ?
Et bien parce que si on ne comprends pas « int is not compatible to CGFloat »*, on ferait mieux de faire autre chose. Ecrire des articles dans un blog qui ne mange pas de pain par exemple. A condition d'avoir là aussi un minimum de compétences, tant en français qu'au sujet de ce dont on parle, n'est-ce pas ?
(*) Comme l'un des types sur Twitter qui dit ne pas comprendre ce message.
@marc_os
Hum là c’est toi l’incompétent, à essayer de faire le malin sans bien lire l’exemple 😅
L’erreur de 5.1 est mal positionnée + mauvais types (classique avec SwiftUI, les erreurs s’affichent quelques lignes plus bas 🤷♂️)
L’erreur avec 5.2 se trouve sur la bonne ligne et indique la bonne erreur avec les bons types (binding int et binding string)
Le développeur ne savait pas que ce truc n’était pas capable d’afficher « 0 » sans le convertir préalablement en string. Franchement ça arrive aux meilleurs ! Surtout sur ce tout nouveau framework
@ marc_os :
Bravo pour cette superbe démonstration d’incompétence doublée d’arrogance ! :-)
La détection des erreurs avec SwiftUI était jusque là catastrophique. Son seul mérite était de signaler qu’une erreur existait quelque part dans le bloc concerné — ou pas trop loin —, mais on ne pouvait se fier ni à la localisation indiquée, ni au message d’erreur, tous deux n’ayant généralement aucun rapport avec la réalité.
On pouvait certes positiver en voyant ça comme un jeu amusant, mais il est plus que probable que beaucoup vont applaudir cette mise à jour (c’est déjà le cas, d’ailleurs).
@BeePotato et Thms
Visiblement vous confondez la correction de bogues dans l'affichage des erreurs par Xcode avec ce dont parle l'article, « des messages d’erreur plus utiles ».
Cf. aussi « ses [Xcode] messages d’erreur sont souvent assez obscurs et n’aident pas à comprendre ce qui ne convient pas. Swift 5.2 devrait améliorer ce point, comme en témoigne cet exemple »
Qui est incompétent ?
@ marc_os :
On ne confond rien du tout.
Tu sembles persuadé que ce dont parle l’article est quelque chose comme une meilleure formulation de messages d’erreur, mais ce n’est absolument pas ça.
Ça parle des améliorations apportées au système de diagnotic du compilateur de Swift, améliorations que tu peux trouver présentées dans le billet « New Diagnostic Architecture Overview » sur le blog de swift.org. Comme on peut le voir à la fin du billet en question, et comme Douglas Gregor l’a expliqué dans un résumé des avancées des « function builders », les progrès apportés par ce nouveau système de diagnostic se remarquent surtout avec SwiftUI, avec plusieurs cas de figure où on avait auparavant droit à un message d’erreur totalement fantaisiste et mal placé, alors qu’on a maintenant droit à une détection efficace de la vraie erreur.
C’est ce qu’on voit dans l’exemple montré ici dans l’article. Contrairement à ce que tu sembles croire, le problème n’était absolument pas que certains développeurs auraient été incapables de comprendre un message leur expliquant qu’un Int n’était pas convertible en un CGFloat optionnel. Le problème était que l’erreur présente dans le code n’avait absolument aucun rapport avec la conversion d’un Int en CGFloat, et n’était absolument pas située au niveau de la méthode .frame(maxwidth:).
L’erreur, comme indiqué correctement par le compilateur de Swift 5.2, était une ligne au dessus (au niveau du TextField) et concernait la tentative d’usage d’un binding sur un entier là où est attendu un binding sur une chaîne de caractères.
Bref, encore une fois : tout ça n’a strictement rien à voir avec de soi-disant développeurs incompétents incapables de comprendre des messages d’erreurs simples. Ça parle d’une grosse amélioration du système de diagnostic qui va rendre bien plus agréable le développement avec SwiftUI.
« Qui est incompétent ? »
Hum.