Développeurs : les petites nouveautés de Swift 4.2, en attendant Swift 5

Nicolas Furno |

Pour la première fois depuis la présentation initiale de Swift à la WWDC 2014, Apple n’a pas présenté de mise à jour majeure à sa conférence dédiée aux développeurs. La cinquième version de Swift a bien été évoquée à la WWDC 2018, mais elle sortira l’année prochaine. Un retard par rapport au planning initial qui prévoyait un lancement cette année. Pour autant, les développeurs ne sont pas repartis bredouilles de San José.

La première bêta de Swift 4.2 a été publiée dans la foulée de la conférence et cette version contient plusieurs nouveautés détaillées dans une session de la WWDC 2018. Petit tour d’horizon rapide de ce qui va changer dès la rentrée avec Swift 4.2, et surtout en 2019 avec Swift 5.

Swift 4.2, une étape de parcours pour aider les développeurs

Même si elle a le numéro de version d’une mise à jour mineure, Swift 4.2 est une version importante, a clairement expliqué Apple pendant la session dédiée à son langage de développement. Néanmoins, cela ne se verra pas forcément, puisque c’est avant tout une étape significative vers Swift 5 qui sortira dans un deuxième temps. Précisons encore que cette mise à jour est actuellement bêta et qu’elle sera finalisée en même temps que toutes les autres nouveautés logicielles, à l’automne prochain.

Comme avec iOS 12, les ingénieurs de Cupertino se sont concentrés sur la vitesse pour Swift 4.2. En particulier, les compilations d’apps écrites avec cette version sont plus rapides lors de la phase de debug, c'est-à-dire quand le développeur teste des changements en local, dans le simulateur ou directement sur un appareil. En fonction du projet, on peut attendre des compilations plus de deux fois plus rapides avec Swift 4.2 et Xcode 10.

Les progrès viennent surtout de l’outil de développement d’Apple, comme nous vous l’expliquions dans un précédent article. La compilation se fait en parallèle, ce qui explique d’ailleurs que les gains seront plus significatifs sur les Mac qui disposent d’un grand nombre de cœurs. Par ailleurs, Apple a optimisé le processus pour réduire le nombre de tâches redondantes et ainsi gagner du temps pendant la création d’une app.

Xcode, toujours, propose de nouvelles options pour les compilations. Pendant la phase de debug, quand le développeur teste son app sans la publier, une préférence permet de réduire l’optimisation et ainsi compiler le programme plus rapidement, au détriment des performances. Du côté du langage, plusieurs optimisations ont été menées, notamment dans la gestion du texte, à la fois pour améliorer la vitesse d’exécution et l’utilisation de la mémoire.

Notons aussi que Xcode 10 dispose d’une option qui optimise la compilation pour le poids du code en langage machine généré dans le processus. Ça ne réduira pas nécessairement le poids de l’app elle-même, puisque cela dépend avant tout des ressources annexes, par exemple des images utilisées par l’app. Mais c’est un levier proposé aux développeurs pour qui les performances brutes ne sont pas l’essentiel. En échange d’une réduction de 10 à 30 % du code généré, la baisse de performances se limite à 5 % en général d’après Apple.

Depuis la sortie de Swift 4, la syntaxe du langage est désormais stable, ce qui veut dire que des lignes de code écrites pour Swift 4.0 seront parfaitement compatibles avec la version 4.1 sortie il y a quelques mois, et avec la 4.2 qui sortira à l’automne. C’était une promesse d’Apple l’an dernier et l’entreprise s’y tient logiquement, mais cela n’empêche pas cette version d’introduire plusieurs nouveautés.

Nous n’allons pas détailler ici les nouvelles fonctions proposées cette année aux développeurs. Elles sont évoquées dans la session d’Apple ainsi que résumées dans ce Swift Playground interactif qui permet de les tester directement. Parmi toutes les nouveautés, évoquons tout de même celle qui est la plus facile à comprendre et expliquer : Swift 4.2 dispose d’une méthode simple pour générer des nombres aléatoires. Aussi étonnant que cela puisse paraître, le langage d'Apple ne proposait rien de tel auparavant et les développeurs devaient utiliser du C pour cette fonction assez basique et courante.

Xcode 10 propose de convertir le code écrit en Swift dans la dernière version du langage. Ce qui permet de bénéficier des nouvelles fonctions dans un projet, automatiquement quand c’est possible.

Point important, Xcode 10 sera la dernière version à prendre en charge le « mode Swift 3 » et donc à pouvoir compiler des apps écrites avec cette version du langage. Xcode 11 commencera avec Swift 4.0 au minimum et tous les développeurs devront avoir converti leur projet à cette date… ou bien continuer à utiliser une ancienne version. Ce qui est toujours possible, Xcode 9 restant disponible et pris en charge pendant un an encore au moins.

À ce sujet, macOS Mojave réduira toutefois les options, puisque ni Xcode 7, ni Xcode 8 ne peuvent être lancés sur ce système, alors que c’était encore possible jusqu’à High Sierra. On pourra en revanche continuer d’utiliser Xcode 9, qui est d’ailleurs installé par défaut en parallèle de Xcode 10 pendant la phase de bêta. Swift 3 sera donc la version la plus ancienne du langage qu’il est possible de compiler sur un Mac et Apple est très claire sur le sujet, cela ne devrait pas durer.

Xcode 7 refuse obstinément de se lancer sur macOS Mojave, au moins à ce stade du développement. C’était la dernière version capable de compiler du code Swift 2.

Swift 5 : enfin l’intégration au système

Swift 4 devait apporter la stabilité du code source et la stabilité des binaires, deux enjeux importants pour généraliser le langage et qu’il serve dans tous les cas de figure (lire : La stabilité, principal enjeu de Swift 4). Finalement, seul le code source a été stabilisé l’an dernier et ce n’est toujours pas en 2018 que l’édifice sera complété. Il faudra attendre Swift 5, prévu pour le début de l’année prochaine comme on le disait en préambule, pour bénéficier de la stabilité ABI.

Pour faire (très) simple, les ABI (Application Binary Interface) sont des briques de bas niveau qui font le lien entre l’app écrite par le développeur et le langage machine exécuté par le processeur. Avec Objective-C, ces briques sont intégrées directement dans iOS (ainsi que macOS, watchOS et tvOS) et une app peut compter dessus sans problème, quelle que soit la version du système. Swift a commencé son existence sans cette assurance : chaque app doit intégrer les ABI dans ses ressources, les systèmes ne fournissent rien.

Chaque app écrite en Swift doit embarquer ces fichiers avec tout le reste pour fonctionner correctement sous iOS. À partir de Swift 5, ces fichiers seront intégrés directement dans le système.

Quand un langage de développement est tout nouveau, cette approche reste indispensable pour ne pas bloquer ses évolutions dans les premiers temps. Swift a beaucoup évolué en quatre ans et les ABI ont été modifiées à plusieurs reprises pour s’adapter aux changements apportés au langage. Mais la contrepartie, c’est qu’une app créée avec Swift 1 risque de ne plus bien fonctionner, voire de ne plus fonctionner du tout aujourd'hui. Chaque mise à jour du système nécessite aussi une mise à jour des ABI et donc une nouvelle compilation.

Swift se stabilise, Apple a cessé d’introduire des changements cassants dans le code source et l’entreprise travaille depuis plusieurs années sur la stabilité ABI. Elle devrait enfin arriver en 2019 et l’entreprise a déjà annoncé que les mises à jour annuelles correspondantes de ses systèmes d’exploitation seront les premières à intégrer les binaires. À partir d’iOS 13 et de macOS 10.15, les développeurs pourront compiler une app sans ABI, ce qui permettra d’alléger le fichier final et apportera quelques optimisations.

Du côté du poids des apps, le gain pourra être très significatif pour les plus légères, comme notre app iOS. La version actuelle d’iGeneration iOS pèse environ 77 Mo, dont 27 Mo rien que pour les binaires indispensables à Swift. Plus du tiers du poids total de l’app pourra être éliminé quand ces nouveautés seront déployées. Apple promet d’autres gains pour les utilisateurs : les temps de lancement devraient être plus rapides, ce sera aussi un gain en matière de mémoire vive consommée, bref des performances en hausse grâce à cette meilleure intégration.

Pour les développeurs, Swift 5 sera l’étape à partir de laquelle ils auront l’assurance d’écrire du code et surtout de créer des apps qui fonctionneront sans problèmes sur les futures versions des OS Apple. Naturellement, il y aura toujours des changements dans les API et des nouveautés à prendre correctement en charge. Mais jusque-là, même les apps les plus basiques pouvaient casser à chaque mise à jour annuelle d’iOS et des autres systèmes.

Certains attendaient cette étape pour franchir le pas et abandonner Objective-C au profit de Swift, la version 5.0 devrait ainsi attirer davantage de développeurs. Y compris au sein d’Apple, où Swift reste encore le langage minoritaire, même s’il gagne du terrain chaque année.

avatar Gueven | 

@fte

POA c’est 1998-1999.

avatar fte | 

@Gueven

Non. Le "tissage de code" est récent, introduit par AspectJ de Xerox (encore eux) sauf erreur.

La notion de pattern visitor, join points, extensions de classe et autres mécaniques AOP, avec ou sans support explicite par le language, sont très antérieurs et remontent à Smalltalk.

avatar Barijaona | 

1/ Pour l’instant, le principal avantage que je vois pour Swift sur Objective-C est qu’il permet d’attirer de jeunes développeurs qui ont tendance à considérer le C comme quelque chose de confus et obsolète.

2/ « À partir d’iOS 13 et de macOS 10.15, les développeurs pourront compiler une app sans ABI, ce qui permettra d’alléger le fichier final et apportera quelques optimisations » : cela ne sera vrai que si l’on ne prévoit de déployer que sur ces versions d’OS et leurs successeurs… En développement Mac, il faut souvent garantir la compatibilité avec des anciennes versions d’OS, donc on ne pourra pas se passer des ABI dans le déploiement des logiciels.

avatar Rez2a | 

@Barijaona

Pour le /2, peut-être que ça concernera également les applis macOS distribuées sur le Mac App Store ?

Parce qu’on a la même problématique sur iOS en fait, c’est assez rare de target uniquement la dernière version du système (surtout a la release ; il faudrait être fou pour target uniquement iOS 12 sur une appli qui serait mise à jour en Septembre).

Mais j’imagine que c’est l’App Store qui se chargera de distribuer (ou non) le runtime Swift à l’appareil téléchargeant l’appli en fonction de sa version d’OS, de la même manière qu’il distribue uniquement les assets nécessaires à son appareil (iPhone / iPad, @2x / @3x...).
On peut imaginer que ça fonctionnerait de la même façon sur le Mac App Store.

avatar denisnone | 

J’ai l’impression que chez macg.co les gens ne comprennent pas vraiment ce que c’est ABI. Vous continuez à répéter chaque fois que Swift 5 nous permettra de fournir les applis « sans ABI ».
ABI c’est Application Binary Interface.
Comment vous imaginez que l’application peut exister sans interface?
L’interface comprends les conventions comment une appli peut interagir avec les bibliothèques “.dylib” de Swift et grâce à ça avec le système d’exploitation.
Donc en gros Swift 5 nous permettra de ne plus fournir les bibliothèques Swift à l’intérieur de notre app puisque ces bibliothèques seront génériques et intégrées dans OS grâce à interface ABI stable.

avatar Mrleblanc101 | 

@denisnone

C’est exactement mot pour mot ce que l’article dit...

avatar ElFitz | 

Depuis Swift, je peux davantage me concentrer sur sortir des features, régler des bugs et l'UX.

Mais surtout que ceux que ça amuse de jouer aux pointeurs, pointeurs nuls, aux variables mutables, aux boucles, et ne parviennent pas à voir l'intérêt des génériques et des protocoles continuent. C'est leur temps, leur énergie, et leur bonne humeur.

Moi je vais mieux depuis Swift. Et pourtant j'ai appris en C.

avatar oomu | 

j’ai du mal à comprendre les discours tel « Le C confus et obsolète ».

Confus . c’est une syntaxe simple avec quelques concepts de base. Très épuré. J’aurais d’avantage accepté ce mot pour C++ dont certains ajouts sont un peu ésotérique à retenir.

Obsolète ? encore une fois ce langage est partout. Il est un des piliers de l’industrie et continue à être la référence pour tout ce qui est embarqué, système et matériel.

Après... ce n’est qu’un pilier. Y en a plein d’autre. Java, qui fut une plateforme complète et de premier choix pour créer des applications clients/serveurs, très utile pour les entreprises de commerces et bancaires.

Python, qui s’est répandu rapidement comme langage de prototypage, d’utilitaires, serveur web, etc, sans se prendre la tête avec de la compilation ou l’incohérence d’un php.

Fortran, Cobol, Perl, java/ecmascript, scripts bash (vi je sais :) ), C#, et autres Lisp, Scheme, et j’en passe et j’y rajoute dans le tas awk et regexp parce que je suis chafouin.

Vous n’arriverez jamais à avoir une réponse à votre interrogation mystique. Il vous faut dans votre besace un ensemble d’outils, au cas où, tous sympathiques, et cela sans mépris. Ils ont tous un sens.

avatar pecos | 

+1.
Ce n'est pas pour rien que c'est toujours autant employé depuis que ça existe.
Parce qu'on ne peut pas s'en passer.

avatar smog | 

En tous les cas, les élèves qui apprennent le Python en lycée sont relativement à l'aise en Swift, bien plus qu'en C.
Ça n'aura pas, évidemment, d'incidence particulière parce quoi est devant un public d'amateurs, mais en tous cas j'en connais qui programment en Swift et qui ne l'auraient pas fait en C ou Obj-C.
Voilà, un apport qui vaut ce qu'il vaut, mais qui est un fait.

avatar 6ix | 

Pour ceux qui ne voient pas l’intérêt à faire autrement que C ni les avantages de Swift, cet article est intéressant : https://stefan-lesser.com/2018/06/20/on-apples-love-affair-with-swift/

Si Swift n’était que du sucre syntaxique au-dessus de C, il n’aurait que peu d’intérêt par rapport à Objective-C. Un de ses objectifs est justement de le rendre beaucoup plus sûr que C.

Ça ne remet ni en question C ni le fait d’apprécier Objective-C, mais fait de Swift un langage très intéressant. Je ne vois pas l’intérêt de redevelopper une app Obj-C en Swift, en revanche Swift peut être utilisé pour de nouvelles fonctionnalités au sein du code Obj-C (pas toujours simple, mais tout à fait faisable) et pour un nouveau projet je ne vois personnellement aucune raison de ne pas utiliser Swift dès le début.

Je dirais qu’actuellement les avantages de Swift sont malheureusement en partie compensés par ses désavantages, mais ces derniers sont essentiellement liés aux outils et à la jeunesse du langage, qui vont donc s’amenuiser.

avatar Mike Mac | 

React Native est notre ami pour iOS et Android !

"React Native est une technologie très prometteuse avec un énorme potentiel, qui a déjà été dûment appréciée par des géants comme Airbnb, Baidu, Discovery, Instagram et d’autres . Constamment améliorée et mise à jour par ses fondateurs, elle est à deux pas de devenir une alternative à part entière à Objective C, Swift et Java. En résumé, le workflow de dev mobile devient celui du web, sans temps de compilation, avec la puissance et la simplicité de React."

https://www.arca-computing.fr/react-native-une-bonne-alternative-au-developpement-natif/

avatar Gueven | 

@Mike Mac

Disons ce ça donne accès (comme electron sur desktop) aux développeurs web de développer des apps mobiles sans changer leurs habitudes et en réutilisant une partie du développent front.

Ce n'est pas une solution à tout.

avatar polaroid62 | 

Java a beau être utilisé sur des milliards de périphériques ça ne veut rien dire,à ce compte Cobol est génial et PHP aussi depuis le temps alors que qui connaît l’histoire sait que la chance a joué .Pour moi swift reprend les avantages des Ruby,Python mêlé à ceux de Scala,Ocaml c’est la voie à suivre et un développeur censé l’avouera.

avatar fte | 

@polaroid62

"et un développeur censé l’avouera."

Ah bin tiens. Les développeurs insensés apprécieront. Infatué et insultant, quelle merveilleuse façon de dialoguer.

Que disait Coluche déjà ? Quelque chose avec l’ouvrir et ne laisser aucun doute.

avatar IGerard | 

Si vous voulez aller dans le concret sur les outils de dev, Swift, SceneKit, AR, Audio ... un joli projet à récupérer :

Check out Inside SwiftShot: Creating an AR Game from #WWDC18

https://developer.apple.com/wwdc18/605

Le projet est dans les ressources associées...

avatar Gueven | 

Les monades par exemple ont été définies mathématiquement en 1980 (concept) et formalisés en 1991.
Aujourd’hui Haskell les remets au goût du jour.
On est très loin de Lisp et de l’origine du fonctionnel.

Tu sembles tout vouloir donner comme origine Lisp, Smalltalk ou Simula.

avatar fte | 

@Gueven

Le lambda calculus est bien plus ancien, Alonso Church, années 30, bien avant LISP. Ce langage n’est que le résultat appliqué de 30 ans de travaux théoriques et appliqués, eux-mêmes reposant sur des travaux antérieurs donc Pascal.

Quant aux monads, ils originent de la théorie des catégories et remontent aux années 40.

avatar Vivid (non vérifié) | 

le C me suffit amplement alors pourquoi utiliser un langage comme swift ou objective C ?
perdre du temps pour faire plaisir a Apple???
m$ a ces API utilisable en C, sur linux ou unix no problemo.
Alors si ils ont rien a foutr.. chez Apple qu'ils se concentre sur autre chose..

avatar fte | 

@Vivid

Poursuivons ce raisonnement jusqu’au bout.

Tout est utilisable en assembleur. Mieux, tout est utilisable en binary code. Seul outil nécessaire, un éditeur hexadécimal. Même pas hexadécimal, un éditeur binaire serait suffisant, et il n’y a besoin que de deux touches sur le clavier. 105 c’est beaucoup trop.

Le plus fort, on peut faire de l’OOP et du fonctionnel si on a un peu de talent, en code binaire et deux touches.

Ou un poinçon et des cartes en fibre de verre.

Pages

CONNEXION UTILISATEUR