Swift est le langage de programmation d’avenir pour Apple. L’entreprise espère remplacer à terme Objective-C par ce nouveau venu né en interne et qui dépasse désormais le cadre strict de Cupertino en étant un langage open source que n’importe qui peut exploiter.
Parti de zéro, ce langage a beaucoup évolué depuis sa première apparition publique, il y a près de trois ans. Apple avait prévenu dès le départ que c’était un projet en cours et à chaque mise à jour annuelle, Swift a évolué de manière significative. Ses concepteurs ont ajouté des fonctions importantes et surtout modifié des fonctions existantes, obligeant les développeurs à modifier leurs apps. Voire, dans certains cas, à repartir de zéro.
Le nouvel enjeu pour Swift est désormais la stabilité. Elle était déjà évoquée pour la troisième version sortie l’an dernier, mais le passage en open source a obligé Apple à revoir ses priorités. Swift 4 devrait être présenté à l’occasion de la WWDC de juin et la stabilité fait partie de ses objectifs.
Qu’est-ce que la stabilité pour Swift ? On fait le point !
La stabilité du code source est en bonne voie
Pour atteindre une stabilité identique à celle d’Objective-C, Swift doit d’abord garantir aux développeurs que leur code source restera compatible d’une version à l’autre. Pour y parvenir, c’est assez simple sur le papier : la syntaxe ne doit pas changer, pas plus que les noms des différentes fonctions indispensables.
C’est simple en théorie, mais en pratique c’est une autre affaire pour un langage aussi jeune que l’est Swift. S’engager sur la stabilité du code dès le départ aurait contraint Apple à bloquer son nouveau langage dans son état initial. Ce qui n’aurait pas été une bonne idée : quand les développeurs du monde entier ont commencé à l’utiliser sur leurs projets, de nombreux problèmes ont été révélés.
Les premières mises à jour de Swift ont largement modifié le langage et sa syntaxe. Certaines fonctions ont été revues entièrement parce qu’elles ne convenaient pas à l’usage, d’autres ont été ajoutées. Ce travail a été permis précisément parce qu’Apple a choisi dès le départ de ne pas stabiliser le code source. Les développeurs qui ont utilisé Swift 1 savaient que leur travail ne serait pas compatible avec Swift 2, et pareil avec Swift 3.
Apple a tout fait pour simplifier le processus à chaque mise à jour. L'environnement de développement Xcode intégrait à chaque mise à jour majeure des algorithmes capables de convertir automatiquement le code source. C’est du temps gagné pour les développeurs, mais ces fonctions automatiques ne peuvent pas tout faire et les changements sont souvent trop importants pour qu’un travail manuel ne soit pas nécessaire derrière.
Pour offrir une stabilité du code source, Swift doit garantir à tous les développeurs que le code qu’ils écrivent aujourd'hui sera encore parfaitement compatible dans le futur. Cela ne veut pas dire que le langage ne pourra plus évoluer, mais les évolutions devront ajouter des éléments et non en retirer. Et en cas de modification d’un élément déjà présent, il faudra s’assurer que les changements ne cassent pas la syntaxe déjà existante.
Pour faciliter les futurs ajouts et changements du langage, Swift 3.1 a amélioré l'attribut @available(). Il permet désormais à un développeur de conserver une partie de son code, même s’il n’est plus valide. Le compilateur chargé de transformer les lignes de code en un programme exécutable pourra gérer ces lignes en théorie incompatibles en utilisant une ancienne version de Swift. Cet ajout permettra à Apple d’avancer à un rythme soutenu sans casser pour autant la stabilité du code source pour ses développeurs.
La stabilité ABI, un enjeu important et complexe
La stabilité du code source est pratiquement assurée pour Swift 4. Néanmoins, ce n’est que la première étape et le langage devra encore assurer une stabilité ABI, ce qui est encore plus difficile. Déjà prévue pour Swift 3, elle pourrait être retardée encore un petit peu, pour de bonnes raisons.
Pour commencer, il n’est pas inutile d’expliquer rapidement ce qu’est une ABI (Application Binary Interface). Cette interface binaire-programme est une brique de bas niveau qui s’intercale en général entre les applications et le système d’exploitation. C’est elle qui fait le lien entre le programme créé par le développeur et le langage machine, c'est-à-dire la suite de bits qui sera exécutée par le processeur.
macOS et iOS sont livrés avec les ABI indispensables à Objective-C. Un programme codé dans ce langage peut ainsi être exécuté uniquement après compilation de son code source. En revanche, les ABI nécessaires à Swift ne sont pas encore intégrées dans les systèmes d’Apple. Pour qu’une app codée avec ce langage fonctionne, elle doit ainsi être accompagnée de ses propres ABI qui feront le lien avec le processeur.
Très concrètement, toutes les apps codées en Swift intègrent une série de fichiers, des bibliothèques dynamiques (extension .dylib) qui font office d’ABI. C’est le cas sur iOS comme sur macOS et tant que la stabilité ABI ne sera pas atteinte, ce sera toujours le cas.
Cette approche a deux inconvénients. Le premier, plutôt mineur, est qu’elle alourdit le poids des applications elle-même. Le fichier total est plus lourd de 10 à 20 Mo en moyenne quand une application exploite Swift par rapport à une autre qui n’est codée qu’avec Objective-C. C’est un problème en soi, mais pour une part croissante des apps disponibles, c’est un surpoids assez marginal.
L’autre inconvénient est plus gênant. Puisqu’une app intègre ses propres ABI, elle reste en partie figée dans le temps et ne bénéficie pas d’évolutions potentielles de la plateforme. Si Apple améliore les ABI dédiées à Objective-C, par exemple pour améliorer la gestion de la mémoire, toutes les apps développées avec ce langage en bénéficieront. Si l’entreprise fait la même chose pour Swift, les applications devront être mises à jour pour bénéficier des changements.
La stabilité ABI est un enjeu également essentiel, mais l’atteindre est plus difficile et prendra peut-être davantage de temps que la stabilité du code source. Il faut dire qu’une fois décrétée, elle limite les possibilités d’évolution en devant s’assurer que les ABI restent compatibles avec toutes les applications existantes. En cas d’incompatibilité, toutes les applications sorties après la stabilisation et sans ABI intégrée pourraient être bloquées.
Apple doit s’assurer que les ABI sont complètes et suffisamment mûres pour les stabiliser. Pour cela, il reste encore du travail, notamment sur l’utilisation de la mémoire, un point qui est géré directement par ces interfaces. Chris Lattner, le créateur de Swift qui dirigeait l’équipe en charge du langage avant son départ pour Tesla, explique dans une interview qu’il y a tant de travail que cet objectif ne sera peut-être pas atteint pour Swift 4.
Il ajoute que ce n’est pas forcément la tâche la plus importante pour Swift à court terme. La priorité serait plutôt d’améliorer le compilateur et notamment sa fiabilité et sa rapidité, en particulier sur les plus gros projets. Les messages renvoyés lors d’une erreur doivent aussi être plus clairs, ajoute Chris Lattner qui considère donc que ce devrait être la priorité, avant la stabilisation des ABI.
Précisons que ce n’est plus lui qui dirige le projet au sein d’Apple. Néanmoins, il semble que Ted Kremenek, son successeur, soit sur la même longueur d’ondes.
Pour conclure
Que la stabilité ABI accompagne la stabilité du code source avec Swift 4 ou qu’elle soit reportée à une future version, il n’en reste pas moins que c’est désormais l’un des plus gros enjeux du langage. C’est une étape indispensable avant sa diffusion plus large et notamment son utilisation dans les systèmes d’exploitation d'Apple.
Dans la même interview, Chris Lattner expliquait d’ailleurs que la stabilité ABI était un prérequis pour que les développeurs de frameworks adoptent Swift. Plus que la syntaxe de base d’un langage, ce sont eux qui sont primordiaux, puisqu’ils permettent aux développeurs de créer leurs applications. Les frameworks servent notamment à accéder au matériel, par exemple pour prendre une photo directement dans une app.
Les développeurs peuvent déjà créer des apps complètes et complexes en Swift. Mais pour qu’Apple utilise plus largement son propre langage en interne, la stabilité est la prochaine étape cruciale.
