Avec le lancement de plusieurs nouveaux systèmes d’exploitation, Apple a publié une nouvelle mouture majeure de son environnement de développement Xcode. À ses côtés est apparu Swift 4, qui engrange lui aussi les nouveautés, même si la stabilité de l’ABI n’est pas encore là.

Depuis cette semaine, iOS 11, tvOS 11 et watchOS 4 sont disponibles pour les possesseurs d’appareils compatibles. iOS 11 contient notamment une très longue liste d’apports (voir notre analyse), notamment pour les développeurs. Alors que le lancement de High Sierra, le nouveau macOS, est prévu pour ce soir, il est possible d’installer Xcode 9 pour prendre en charge les évolutions de ces plateformes. 

Xcode est l’environnement de développement intégré d’Apple. Ses améliorations s’accompagnent en général de celles de Swift, le langage maison conçu pour remplacer Objective-C, avec l’objectif affiché d’accélérer le travail des éditeurs concernés. La version 9 de l’IDE continue donc son chemin et embarque pour l’occasion Swift 4. Le langage, devenu open source depuis sa mouture 3.0, peut cependant être utilisé ailleurs.

Une simplification du débogage pour les appareils iOS et l’Apple TV

Xcode 9 commence par intégrer une nouveauté attendue de longue date par les développeurs iOS. Une fois qu’un iPhone ou un iPad a été branché une première fois sur le Mac (l’IDE réclame toujours macOS pour fonctionner), il peut être configuré pour un débogage en réseau. Une simplification du processus, qui réclamait jusqu’ici que les appareils soient tous raccordés à la machine. Idem pour l’Apple TV, qui peut donc rester à côté du téléviseur après la première configuration.

L’apport est loin d’être anodin. Si le développeur doit s’assurer du bon fonctionnement de son ou ses applications sur toute une variété d’appareils mobiles, le fait de ne pas avoir à les brancher est clairement une amélioration. C’est particulièrement vrai pour ceux qui seraient en déplacement et n’auraient pas sous la main de Mac disposant d’un nombre suffisant de ports USB.

Une bonne cuvée pour le simulateur 

Les émulateurs sont une autre part importante des IDE. Pas étonnant notamment que Google ait largement retravaillé le sien dans Android Studio, pour en augmenter surtout les performances. Ils permettent de tester rapidement les applications sans avoir à les envoyer sur un appareil pour en observer le comportement.

Plusieurs améliorations majeures font donc leur apparition. D’une part, le développeur peut maintenant démarrer plusieurs simulateurs en même temps, par exemple un pour iOS et l’autre pour watchOS. D’autre part, il est enfin possible de déclencher un enregistrement vidéo depuis ces simulateurs, par exemple pour montrer comment un bug particulier se manifeste.

Les autres nouveautés sont de type « quality of life ». Ainsi, les fenêtres de simulateurs présentent les contrôles matériels des appareils associés et peuvent plus facilement être déplacées ou redimensionnées. Elles gèrent également les gestes prenant naissance sur le bord de l’écran. Il suffit pour cela de cliquer juste en-dehors de l’écran. Outre une extension Share permettant d’envoyer dans le simulateur des informations certaines applications intégrées (Safari, Plans, Photos…), on notera aussi un respect du dossier déclaré pour le stockage des captures d’écran (qui allaient toujours jusqu’à présent sur le bureau).

Xcode 9 prend enfin en compte GitHub

L’environnement de développement inaugure un nouveau navigateur Source Control, permettant d’afficher toutes les copies du projet ou de l’espace de travail. Toutes les informations principales sont affichées : branches, tags, dépôts distants ou encore le nombre de requêtes push/pull pour chaque branche. Un nouvel écran permet aussi de comparer côte-à-côte les différences entre deux fichiers.

GitHub se joint également à la partie. Le compte se déclare dans les préférences de Xcode. L’authentification à deux facteurs est supportée, de même que l’utilisation d’une clé SSH personnalisation qui sera utilisée à chaque opération depuis et vers le dépôt.

Un premier pas vers le refactoring

Le refactoring (que les Québécois nomment réusinage) est le nom utilisé quand on retravaille le code de manière à le maintenir aussi simple que possible. Les avantages sont nombreux, notamment pour la maintenance ou dans le cadre d’un travail d’équipe, quand d’autres doivent reprendre un code qu’ils ne connaissent pas encore.

On touche ici à l’un des plus gros reproches faits à Xcode : l’absence de fonctionnalités pour simplifier ces opérations. La version 9 en introduit plusieurs, et même s’il s’agit des outils les plus basiques, ils ont enfin le mérite d’exister. Xcode 9 permet donc l’ajout de snippets (portions réutilisables de code), l’extraction de méthodes et de variables, ou encore le renommage global. Ils fonctionnent d’ailleurs aussi bien avec les projets en Swift que les plus anciens en Objective-C.

Puisque l’on parle de faciliter la vie du développeur, le nouvel IDE intègre également un plus grand nombre de « Fix It ». Il s’agit pour rappel d’automatismes permettant de gagner du temps, quand l’IDE détecte une erreur commune ou une situation qu’il juge classique. Par exemple, proposer d’ajouter les surcharges pour les méthodes abstraites, les stubs manquants ou encore les instructions if/else autour d'un appel API n’étant disponible que pour une version spécifique d’iOS.

Un nouveau système de compilation

Xcode 9 change de système de compilation. Réécrit en Swift de zéro selon Apple, il doit permettre une plus grande fiabilité, de meilleures performances et de régler un plus grand nombre de problèmes pendant les opérations, notamment les soucis de configuration dans le projet.

Bien que présent dans l’IDE, le nouveau système n’est pas activé par défaut, car il n’est pour l’instant disponible que sous forme de préversion. Pour l’activer, il faut se rendre dans les paramètres du projet, puis dans ceux de l’espace de travail. Notez qu’il est possible de ne l’activer que pour un seul projet, via le flag -UseNewBuildSystem=YES.

Parmi les autres améliorations, signalons que Xcode Server et xcodebuild supportent désormais les tests en parallèles sur plusieurs appareils et simulateurs, que xcodebuild ne lance plus automatiquement l’émulateur ou encore que le développeur dispose d’un nouveau réglage, CODESIGNSTYLE, qui permet de passer outre le style de signature de la cible, pour le passer en Automatique ou Manuel.

Interface Builder et autres améliorations

La construction des interfaces bénéficie elle aussi de plusieurs ajouts plus ou moins importants. L’apparition des barres, barres d’onglets et barres d’outils sur la surface de travail se fait ainsi de la même manière qu’à l’exécution de l’application, une propriété usesAutomaticRowHeights permet de définir une taille commune à toutes les lignes, on peut nommer les couleurs et le développeur est invité à utiliser textContentType pour les zones concernées, afin que l’API Autofill puisse mieux accomplir son travail.

Parmi les autres améliorations, on pourrait citer la possibilité de modifier la taille du texte dans l’éditeur de sources via la combinaison CMD ++/-, le support du Markdown, le défilement rapide quelle que soit la taille du fichier, une recherche plus rapide, le support de Quick Look pour les variables de certains types (CALayer, PDFDocument, NSImageRep, CIRenderTask, CIContext et CIImage) ou encore, lorsqu’un texte est encadré, l’ajout automatique de deux délimiteurs correspondant au signe de ponctuation tapé (guillemets, parenthèses, crochets et accolades).

Comme on s’en doute également, Xcode 9 supporte l’ensemble des nouvelles API présentes dans iOS 11, tvOS 11, watchOS 4 et macOS High Sierra, qui arrive ce 25 septembre. Parmi les principales nouveautés, on citera Metal 2 pour tout ce qui est graphique, CoreML pour les activités dévolues à l’intelligence artificielle, ainsi qu’ARKit, qui permet aux applications de tirer parti de la réalité augmentée sur les appareils iOS.

Compatibilité, téléchargement et soucis de stabilité

Question compatibilité par contre, la recette ne change pas. Bien que gratuit, l’environnement de développement se télécharge obligatoirement depuis le Mac App Store sur la dernière révision en cours de macOS, à savoir Sierra (version 10.12.6 minimum exigée).

Attention cependant, car si l’on en croit certains commentaires laissés par les développeurs, des soucis de stabilité sont présents dans cette version finale, au point que utilisateurs se demandent si la phase bêta n’aurait pas dû continuer un peu plus. Lenteurs et plantages nuiraient globalement à l’ensemble, en dépit des apports.

À moins que les développeurs aient une urgence particulière à récupérer Xcode 9.0 – par exemple pour la création d’une application visant spécifiquement iOS 11 – beaucoup attendront donc les révisions mineures et leurs correctifs.

Swift 4.0 stabilise le code, mais pas les ABI

L’autre grande nouveauté chez Apple pour les développeurs est l’arrivée de la quatrième version majeure de Swift. Commençons d’emblée par pointer une absence : la stabilisation des ABI.

Les Application Binary Interfaces sont globalement les briques essentielles qui permettent au code Swift de fonctionner, en établissant le périmètre des fonctionnalités disponibles. Tant qu’elles ne sont pas finalisées, elles ne sont intégrées ni dans iOS, ni dans macOS. Chaque application doit donc embarquer ses propres ABI, provoquant un alourdissement (que nous avions d’ailleurs relevé dans notre analyse sur le poids des applications).

Cette stabilisation devrait initialement être atteinte pour Swift 3.0. Apple avait modifié ses plans, le passage à l’open source du langage ayant quelque peu bouleversé le calendrier prévu. L’entreprise avait finalement évoqué Swift 4.0, mais les plans ont encore changé : désormais, ce sera le rôle de Swift 5.0.

Ce qui n’empêche pas cette version 4.0 de stabiliser le code, établissant un important jalon dans l’histoire du langage. Contrairement à l’arrivée de la mouture précédente, les développeurs n’auront donc pas à modifier leur code avec le passage à Swift 4.0. En clair, ils pourront conserver la syntaxe actuelle ou basculer sur la nouvelle.

Dans Xcode 9.0, ils pourront même compiler leurs deux cibles au sein du même projet. Il est donc possible de profiter des nouveautés de la version 4.0 pour des ajouts sans toucher au reste du code s’il donnait satisfaction. Le mode est indiqué via un flag -swift-version dans le compilateur, suivi de 3.2 ou 4 selon ce qui intéresse le développeur.

Moins de nouveautés, mais plus de fiabilité

Swift 4.0 est clairement moins « cassant » que la version 3.0. Entre la stabilisation du code et la possibilité de marier l’ancienne et la nouvelle version au sein de Xcode, Apple ménage la chèvre et le chou. De fait, contrairement à Swift 3.0 qui brisait de nombreuses habitudes, la nouvelle mouture est davantage une évolution, avec de nombreuses améliorations de l’existant.

Par exemple, l’implémentation de String se veut plus rapide et plus simple à utiliser, en ajoutant notamment la création et la gestion des sous-chaines de caractères. Même chose pour les types Collection. Swift 4.0 rattrape également parfois son retard sur d’autres langages, comme pour les chaines de caractères littérales multilignes. On notera aussi l’arrivée de la propriété unicode Scalars sur le type Character.

La nouvelle version apporte également de nouvelles fonctionnalités pour les flux de travail ainsi qu’une API plus complète pour Swift Package Manager.  Citons ainsi la formalisation des paquets, permettant au développeur de contrôler quelles bibliothèques sont publiées aux clients, la possibilité de définir un plus grand nombre de paramètres pour les paquets, ou encore leur compilation dans une sandbox, coupant tout accès au réseau et au système de fichiers. Ce dernier point doit atténuer le danger des attaques utilisant des manifestes malveillants.

Disponible seulement pour Linux et macOS pour l’instant

Swift 4.0 est disponible essentiellement pour Ubuntu (moutures 14.04, 16.04 et 16.10) et Xcode 9.0, qui réclame lui-même au moins macOS 10.12.6 (Sierra). Le compilateur et tout le nécessaire se trouvent cependant une archive tar.gz que les développeurs peuvent normalement utiliser sur la grande majorité des distributions GNU/Linux.

Pour le reste, rien ne change : ni la liste des plateformes officiellement supportées, ni les emplacements des différents dépôts GitHub (principal, LLVM, Clang…). Il reste possible de développer en Swift sous Windows (le projet est en open source, rien n’empêche donc son adaptation), mais il faudra passer par des outils tiers, comme Swift for Windows, également open source.

Voici pour fini une liste des liens utiles :

• Télécharger Xcode 9.0 (depuis le Mac App Store)
• Télécharger Swift 4.0
• Dépôt GitHub de Swift 4.0
• Nouveautés Xcode 9.0 sur le site d’Apple
• Nouveautés Swift 4.0 sur Swift.org
• Swift for Windows 1.6 sur GitHub