La stabilité, principal enjeu de Swift 4

Nicolas Furno |

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.

Craig Federighi sur la scène de la WWDC 2015, en train d’annoncer le passage en open source de Swift. Cliquer pour agrandir

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.

Voici à quoi ressemblent quelques lignes de code en Swift. Cliquer pour agrandir

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.

Xcode 8 est capable de convertir des lignes de code Swift 2 en Swift 3. Ce processus automatique permet de gagner du temps, mais il ne fonctionne pas à tous les coups.

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.

Hopper, un logiciel pour macOS qui permet de décortiquer un programme en affichant son code assembleur. Cliquer pour agrandir

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.

Toutes les applications en Swift doivent intégrer plusieurs fichiers qui contiennent les interfaces indispensables entre le programme et le processeur. Cliquer pour agrandir

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.

Craig Federighi sur la scène de la WWDC 2014, lors de la première présentation publique de Swift. Cliquer pour agrandir

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.

avatar C1rc3@0rc | 

Swift est libre et deja porté sur Linux.
Le probleme de C# c'est que c'est trop lié a .NET et que pour beaucoup c'est trop une reponse pour ne pas adopter Java dont il partage la complication et l'aspect trop verbeux tout en gardant les dangers des pointeurs et des aberations du C comme le switch et ses break.
Apres, sa syntaxe est plus legere que celle de c++ ou d'objective-c, mais ça reste quand meme du C.

avatar pit-le-rouge | 

Oui swift est porté sur Linux. Mais qu'est ce que tu peux faire avec ? A part une app en mode "console" ?
Grâce à Mono, C# est devenu un vrai language multi-plateforme. Le rachat de Xamarin par MS voit arriver Visual Studio for Mac. Bref on est clairement dans une dynamique.
Pour ce qui est des pointeurs, il est vrai qu'ils existent toujours mais leur usage est fortement déconseillé (tu passes d'ailleurs en mode unsafe si tu les utilises).
Il y a tout ce qu'il faut en C# pour se passer des pointeurs. Je ne les ai d'ailleurs jamais utilisé jusqu'à présent.

avatar BeePotato | 

@ pit-le-rouge : « Oui swift est porté sur Linux. Mais qu'est ce que tu peux faire avec ? A part une app en mode "console" ? »

Bah, pour Linux, ça suffit bien. :-)

Blague à part : oui, ça suffit bien dans beaucoup de cas, l’usage de Linux étant très orienté serveur (et c’est pour l’instant le plus gros intérêt que beaucoup voient à Swift pour Linux : écrire en Swift des logiciels pour serveurs, souvent dans la perspective d’accompagner une application iOS développée elle aussi en Swift).

D’autre part, rappelons que si les langages multiplateformes, c’est le bien, en revanche les frameworks pour interface graphique multiplateformes, c’est le mal !

Mais il n’est pas impossible qu’on voit apparaître un jour des frameworks pour interface graphique pour Linux utilisables en Swift, même si l’intérêt pour ça est bien moindre pour l’instant que l’intérêt pour les serveurs.
Et il est bien possible qu’on voit apparaître avant ça une version des frameworks Android utilisable en Swift.

avatar Nico S | 

@pit-le-rouge

Au hasard, une web app avec Vapor ? Une API REST avec Kitura ? C'est vrai, pas super utile ;-)

avatar ovea | 

Et dire que language ne fait pas sens … ça a du sens ?

avatar Ali Baba | 

« 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. »

Heu... ce n'est pas du tout ce que j'ai compris.

avatar mk3d | 

Sans vouloir dire, mais quand même, chaque année a sa nouvelle version de Swift. C'est lourd. Vivement la maturité de ce langage et l'arrêt incessant de nouvelles syntaxes. Sinon que du bonheur Swift!

avatar Ginger bread | 

Bref OSX en swift ce n est pas demain la veille

avatar Domsware | 

Les migrations d'une version de Swift à une autre ne sont pas lourdes du tout. Xcode fait le gros du boulot automatiquement puis il propose des corrections pour une très grosse partie des erreurs non corrigées automatiquement et enfin au peu qui reste est associé un message explicite.

Il ne faut pas oublier non plus que Swift permet la transition depuis Objective-C ce qui explique certains choix initiaux qui sont corrigés par les mises à jour.

Enfin Swift est un langage qui améliore la stabilité des applications ne serait-ce qu'en renforçant le rôle de la compilation dans la détection des erreurs. Autrement exprimé le langage donne les moyens au développeur de détecter ses erreurs plus tôt dans le développement.

avatar fte | 

@Domsware

Pas lourdes ? Définis "pas lourdes".

J'ai passé des jours, semaines, à mettre à jour des codes source, des bourdes de conversion introduites par Xcode, fixer tous les warnings nouveaux liés aux évolutions des API au fur et à mesure des vérifications d'Apple (pointeurs null en particulier, types également)...

Perso j'ai trouvé ces transitions lourdes.

Je ne me plains pas notez bien, j'ai fait des choix assumés sachant pertinemment qu'il y aurait de transitions de ce type.

avatar mbritto | 

Ca dépend évidemment de la taille du projet mais j'avoue que même sur des projets assez conséquents je n'ai jamais dépassé les 2 jours pour faire une migration.

Par contre ce qui est plus compliqué c'est quand on utilise des dépendances qui ne sont pas encore à jour ou qui ont été abandonnées depuis.
J'ai encore mon plus gros projet en Swift 2 car j'utilise un projet Open Source abandonné depuis...

avatar Pancrasse | 

@ Nicolas Furno
Merci pour cet article : c'est ce qu'on aime chez Macg. Des bons articles de vulgarisations et des rumeurs !

avatar Tom.P | 

Puisqu'on parle de stabilité, vous devriez donner votre propre avis MacG vous êtes bien Swifté maintenant dans vos apps ?
Quand est-il pour vous ? :)

avatar oxof | 

Vendredi, 11h16

avatar LaurentH | 

@Tom.P

Il est vrai que la migration de iGeneration 5.1 de Swift 2.3 à 3.0 m'a pris plus de temps que j'aurai aimé, et j'ai eu un peu l'impression de perdre mon temps. Pour moi un language qui change de syntaxe tout les ans c'est nouveau. J'aimais bien le C, langage créé et inchangé depuis 1827. D'ailleurs ça me manque un peu l'arithmétique des pointeurs... et l'assembleur inline. Pour moi le meilleur environnement de dev sur Mac, ça restera Lightspeed C. haha :-)

avatar BeePotato | 

@ LaurentH : « J'aimais bien le C, langage créé et inchangé depuis 1827. »

On oublie facilement que le C aussi a connu de grosses évolutions. Ça s’est stabilisé depuis un moment maintenant (d’où l’oubli), mais cette stabilité n’est pas arrivée tout de suite.
On peut s’amuser, de temps en temps, à écrire un programme avec la syntaxe K&R d’origine pour se rappeler un peu cette évolution. :-)

Certes, ça s’est fait à un rythme bien plus calme que pour Swift. Mais en contrepartie de cette évolution rapide, on devrait voir ce dernier arriver bien plus rapidement à un point où on n’aura plus à réécrire une grosse partie de son code pour passer à la dernière version.

avatar mixo01 | 

Mouai, l'application iPad MacG fonctionne bien sur mon iPad air 2 (heureusement ...) mais sur mon iPad 3, depuis les grosses mises a jour et le passage a swift, c'est tout simplement inutilisable !!! Tout est d'une lenteur affligeante. Et ont ne parle pas d'un jeux video ultra gourmand ou je ne sais quoi, on parle juste d'une application qui affiche des news avec du texte et des images ...

Swift est certainement un language simple mais est-il rapide, j'en doute. Bon après c'est peut-être aussi MacG qui code avec les pieds ...

avatar LaurentH | 

@mixo01

"sur mon iPad 3, depuis les grosses mises a jour et le passage a swift, c'est tout simplement inutilisable !!! "

Jusqu'à récemment j'avais un iPad 3, et l'app était tout à fait utilisable. Bon évidemment pas aussi 'snappy' que sur un iPad Pro, mais largement utilisable quand même... Nous faisons en sorte de tester également l'app sur des appareils anciennes générations (un iPod touch 5G, un iPad mini etc..) pour nous assurer que tout fonctionne de manière acceptable sur ces modèles.

avatar mixo01 | 

C'est peut-être un problème de mon iPad, mais mes autres applications du même type (journaux, app de news) reste fluides sur mon ipad3. Avec l'app macG, l'actualisation des articles est extrêmement lente, et pendant ce temps (environ 10-20 secondes, je viens de refaire la tentative), l'app est inutilisable, saccadée. Ensuite l'application reste utilisable mais très lente: c'est assez dissuasif en fait.
Et pourtant, l'app MacG (enfin la dernière version compatible) sur mon iphone4 (eh oui!) reste relativement fluide et agréable à utiliser.

avatar LaurentH | 

@mixo01

Pour la prochaine version, tout le code réseau et d'accès aux serveurs a été ré-écrit. Normalement il devrait y avoir du mieux avec une actualisation plus fluide entre autre...

avatar mixo01 | 

super!

avatar Vivid (non vérifié) | 

pourquoi faire compliquer quand le C suffit largement...

Pages

CONNEXION UTILISATEUR