Swift 5 va bien réduire la taille des apps
Apple a distribué de toutes nouvelles bêtas d’iOS, macOS, tvOS et watchOS hier soir, mais les développeurs peuvent aussi bénéficier d’une nouvelle version de Xcode. Numérotée 10.2, cette mise à jour intègre plusieurs nouveautés intéressantes pour créer des apps, mais la plus significative est certainement la première bêta de Swift 5.

Swift 5 apporte enfin la stabilité ABI
La cinquième version majeure du langage de développement d’Apple est intégrée à Xcode 10.2 et elle sera compatible avec les nouvelles versions des systèmes d’exploitation aussi en bêta. On l’attendait à l’origine en juin dernier, lors de la WWDC 2018, mais son développement avait été retardé et les développeurs n’ont eu « que » Swift 4.2 à se mettre sous la dent l’an dernier. Ce retard est justifié par l’arrivée d’une fonction attendue de longue date pour le langage de développement d’Apple : la stabilité ABI.
Après la stabilité du code source obtenue avec Swift 4, la stabilité ABI est la dernière brique nécessaire pour stabiliser Swift, étape indispensable de son développement. Comme nous avions eu l’occasion de le détailler dans un précédent article, les ABI font le lien entre le programme écrit par un développeur et le langage machine, la série de bits qui sera exécutée par le processeur. C’est un élément de bas niveau qui est indispensable à tout programme et qui n’était, jusque-là, pas intégré aux systèmes d’exploitation. À la place, les apps intégraient leurs propres fichiers, ce qui avait plusieurs inconvénients.

Le plus évident est que la taille des apps codées en Swift était plus élevée. Avec cette cinquième version, leur poids va au contraire diminuer, puisque les fichiers qui devaient être intégrés auparavant dans les apps ne sont plus nécessaires. Les ABI étant désormais stables, ce lien entre le code et le processeur sera intégré directement dans les systèmes d’exploitation d’Apple.
Les gains à attendre devraient être significatifs, puisque ces fichiers représentent vite plusieurs dizaines de méga-octets. À titre d’exemple, un projet en Swift totalement vide pesait 2,4 Mo avec Swift 4.2, le même avec Swift 5.0 ne pèse plus que 24 Ko. Plus une app sera complexe et plus la différence devrait se sentir.
Il y a d’autres avantages liés à la stabilité ABI, en particulier du côté des performances. En outre, Apple peut améliorer les libraries intégrées à ses systèmes à la faveur d’une mise à jour et toutes les apps développées en Swift en bénéficieront. Auparavant, elles devaient absolument être mises à jour pour profiter des améliorations apportées.
Autres nouveautés dans Swift 5 et Xcode 10.2
Outre la stabilité ABI, Swift 5 apporte plusieurs nouveautés que les développeurs pourront intégrer dans leur code. Il est désormais possible d’enregistrer du texte brut dans une variable, y compris avec des caractères spécifiques qui étaient jusque-là interprétés par le compilateur. Un nouveau type dynamique fait son apparition, ce qui sera utile notamment aux développeurs qui mixent Swift avec un langage dynamique, comme JavaScript. Plus de souplesse également pour les énumérations : il est désormais possible de lister un cas « inconnu », une sorte de réponse par défaut quand les autres ne sont pas valables.

Il y a encore d’autres nouveautés, que vous pourrez découvrir dans la liste des nouveautés publiée par Apple. Vous trouverez également des explications avec des exemples pour chaque fonction dans cet article, ou alors de manière interactive dans ce Swift Playground qui rassemble toutes les nouveautés.
Du côté de Xcode 10.2, la possibilité d’utiliser un serveur de cache macOS pour télécharger des fichiers. Pour rappel, il est possible depuis High Sierra d’utiliser un Mac en guise de cache pour les mises à jour des systèmes et applications, pour les données d’iCloud et maintenant pour les données gérées par Xcode. Ce sera sans doute très utile dans les entreprises où plusieurs développeurs travaillent avec l’outil de développement d’Apple.
Le constructeur annonce aussi avoir corrigé le bug qui a touché, entre autres, Instagram. Dans certains cas, il était impossible de compiler une app optimisée pour les nouveaux iPhone et iPad de 2018 et qui fonctionnait aussi sous iOS 9. Xcode 10.2 règle le problème, il suffira de compiler à nouveau l’app pour avoir les deux, l’interface optimisée et la compatibilité avec iOS 9.
Parmi les petites nouveautés de cette mise à jour, une nouvelle option a fait son apparition dans les préférences de Xcode. Comme son nom l’indique, « Always use Dark » permet d’utiliser l’app en mode sombre, même si macOS Mojave est configuré en mode clair. De manière générale, c’est tout ou rien, mais de nombreux développeurs voulaient Xcode toujours en mode sombre, sans pour autant avoir le système entier dans ce mode. Ils ont été entendus !

Il y a encore de nombreuses autres nouveautés à découvrir dans la liste fournie par Apple. Il y a aussi quelques bugs connus à prendre en compte, cette version n’étant pas encore conseillée en production.
Moi qui allait bientôt finir mon app en Swift 4.2 après un an de boulot, j’espère ne pas trop avoir de taff pour update.
@twistan_
Bon courage ? C’est une app sur quoi ?
@twistan_
On parle de stabilité des ABI, pas de celle du code source. Votre application en Swift 4 reste donc valide. ?
J’avais toujours l’impression que les rédacteurs de MacGco ne comprennent jamais ce que c’est ABI.
ABI ce sont les conventions, c’est pas pas un truc matériel, c’est abstrait. Vous ne pouvez pas les intégrer dans votre app ou dans l’iOS.
Les trucs matériels ce sont les bibliothèques qui adoptent ces ABI, qui suivent on va dire ces conventions.
Et c’est certainement les bibliothèques qui sont intégrées dans votre application, pas ABI. Et les fichiers dylib que vous montrez dans Finder sont pas ABI mais « Libraries » en anglais.
c'est un raccourci de langage. on voit fréquemment cet abus dans les articles en anglais, les forums etc.
Mais l'article lié, celui parlant de l'importance des ABI explique bien qu'on parle en réalité de BIBLIOTHÈQUES (et pas de librérizeus) mettant en œuvre ces fameuses "abi".
"dans un précédent article" -> https://www.macg.co/logiciels/2017/02/la-stabilite-principal-enjeu-de-swift-4-97299 (et effectivement c'est vrai : il est un article qui précède celui là, et il explique en détail de quoi on cause).
Il lève exactement votre angoisse.
@oomu
Bien. Mais je vous en supplie d’arrêter de pulluler le bordel dans les têtes des gens qui vous lisent, c’est tout.
La vérité ne peut pas être sacrifiée à la simplicité surtout dans la matière technique.
Oh là là… les ABI ne sont pas des fichiers, mais des conventions d'interface entre l'application et l'OS, et tant que ces conventions ne sont pas stabilisées, chaque appli Swift 1 à 4 doit embarquer sa propre version des bibliothèques de fonctions sytème, au lieu d'utiliser celles de macOS.
"Apple peut améliorer les ABI dans ses systèmes à la faveur d’une mise à jour et toutes les apps développées en Swift en bénéficieront": c'est justement parce que l'ABI ne changera plus, qu'Apple peut améliorer les BIBLIOTHÈQUES de macOS pour que toutes les apps développées en Swift 5 et ultérieur uniquement en bénéficient.
Oui, vous avez raison, le sujet est abstrait et complexe et j'ai voulu le simplifier au maximum. Mais ce n'est pas une raison pour écrire n'importe quoi.
J'ai corrigé.
diantre, mais alors les commentaires précédents deviennent incompréhensibles :)
@oomu
Arg ! ?♂️
?
« Xcode 10.2 règle le problème, il suffira de compiler à nouveau l’app pour avoir les deux, l’interface optimisée et la compatibilité avec iOS 9. »
Le problème était fixé depuis Xcode 10.1 pour les apps distribuées sur l’AppStore.
Xcode 10.2 corrige ce problème pour les apps distribuées sur un store interne.
Très bonne nouvelle j’espère que ça va réduire le poids de plein d’applications ! Quand on a que 32gb c’est important.
(houps j'ai fait un hors sujet)
Quel pourcentage de réduction de taille on peut espérer pour les apps concrètement ?
Parce que l’exemple d’un projet vide, c’est un peu particulier.
@SimR69
Y a un exemple dans l’article... Divisé par 100! ?
@fernandn Relis, j'ai justement demandé un autre exemple parce que «l'exemple d'un projet vide, c'est un peu particulier» -_-
M'étonnerait que ça divise la taille par 100 dans les autres cas.
@SimR69
Évidemment que cet exemple est excentrique !?
@SimR69
"Quel pourcentage de réduction de taille on peut espérer pour les apps concrètement ?
Parce que l’exemple d’un projet vide, c’est un peu particulier."
Tout ce qu'on espérer c'est une réduction de quelques Mo sur la taille des applications. Les librairies ont une taille fixe, les retirer d'une application peut faire gagner quelques Mo ici et là, sans plus.
Il est difficile de donner des chiffres précis, parce qu'il existe de nombreuses bibliothèques systèmes, avec des tailles variées, allant de quelques Ko à des dizaines de Mo. Chaque application est un cas différent, selon ses besoins. Par exemple, si une application a besoin d'une identification FaceID/TouchID elle doit utiliser une librairie spécialisée qui prend de la place en mémoire (et sur le disque).
L'intérét de Swift 5 est d'éviter la redondance des bibliothèques. Imagine que ton iPhone possède 100 applications intégrant chacune 10 Mo (chiffre estimé au doigt mouillé) de bibliothèques système (composants graphiques, géolocalisation, accès internet, etc..). 100x10 Mo => 1000 Mo (UN GIGA!!) de disque occupés par des choses redondantes !
Le gain de place sera surtout perceptible par les utilisateurs ayant beaucoup d'applications installés sur le même device, comme moi et les 120 jeux installés sur mon iPhone 8+.
Merci pour cette réponse très complète, et effectivement ça me semble logique que ce soit assez variable.
Je n’ai jamais développé sur iOS donc je ne sais pas trop combien pèsent les libs, mais si ton estimation au doigt mouillé se concrétise, ça pourra être très intéressant pour moi aussi car j’ai à peu près le même nombre d’apps ^^
@SimR69
Tu peux ouvrir le paquet d’une application et aller voir, les bibliothèques sont toutes dans le même dossier. Il y en a plus ou moins, selon ce que le programmeur a utilisé parmi les fonctionnalités disponibles.
Sur les grosses applications, le gain sera moins visible que sur les petites.
Mais c’est surtout que beaucoup des bibliothèques « de base » sont présentes dans la moindre applications.
Le gain de place devrait donc être conséquent au final.
Par contre est ce que Apple utilise aussi swift pour ses propres OS ou pas ? Parce que j’ai l’impression qu’ils restent très gros en taille
@corben
En pratique, c’est beaucoup plus complexe que ça.
Un OS est constitué d’innombrables briques qui constituent d’innombrables couches qui fournissent d’innombrables services.
C’est caricatural mais certaines portions de code constituant ces briques sont en Swift. Pour d’autres, ce n’est pas l’outil adapté.
On trouve une multitude de technologies différentes dans le code d’un système d’exploitation comme iOS ou macOS.
J'en reviens pas qu'il ait fallu attendre Swift 5 pour avoir un cas par défaut pour les enum ... Ils ont le else au moins pour la conditionnelle ou faut attendre Swift 23 ?
EDIT : OK j'ai rien dit, apparemment la nouveauté c'est sur le "@unkown"
Justement pour moi qui suis plutôt novice en Swift, je me demande la différence entre cette nouveauté et le "default" qui existait déjà précédemment ?
Mais pour moi qui suis plutôt novice en Swift j'ai du mal à comprendre la différence entre cette nouveauté et le "default" qui existait auparavant ?
EDIT : désolé je croyais que mon précédent commentaire n'avait pas été posté... ?