Swift 5 va bien réduire la taille des apps

Nicolas Furno |

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.

Image Hacking with Swift

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.

Tant que la stabilité ABI n’était pas en place, chaque application devait intégrer des fichiers supplémentaires. Ici, ceux de notre app iGeneration.

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.

L’une des nouveautés de Swift 5, la possibilité de définir un cas inconnu dans une énumération.

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 !

Capture d’écran @bzamayo.

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.

avatar twistan_ | 

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.

avatar Lucas | 

@twistan_

Bon courage ? C’est une app sur quoi ?

avatar minipapy | 

@twistan_

On parle de stabilité des ABI, pas de celle du code source. Votre application en Swift 4 reste donc valide. ?

avatar denisnone | 

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.

avatar oomu | 

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-sw... (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.

avatar denisnone | 

@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.

avatar jerome74 | 

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.

avatar Nicolas Furno | 

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é.

avatar oomu | 

diantre, mais alors les commentaires précédents deviennent incompréhensibles :)

avatar Nicolas Furno | 

@oomu

Arg ! ?‍♂️

?

avatar Ded77 | 

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

avatar Woaha | 

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.

avatar oomu | 

(houps j'ai fait un hors sujet)

avatar 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.

avatar fernandn | 

@SimR69

Y a un exemple dans l’article... Divisé par 100! ?

avatar SimR69 | 

@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.

avatar fernandn | 

@SimR69

Évidemment que cet exemple est excentrique !?

avatar IceWizard | 

@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+.

avatar SimR69 | 

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 ^^

avatar Finouche | 

@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.

avatar corben | 

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

avatar minipapy | 

@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.

avatar Petrichor | 

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"

avatar loulolj914 | 

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 ?

avatar loulolj914 | 

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é... ?

CONNEXION UTILISATEUR