Xcode 14 a accidentellement augmenté le poids de nombreuses apps
Xcode 14, l’environnement de développement fourni par Apple, promettait d’alléger les apps compilées par ses soins, en particulier celles qui tournent sous iOS 16 et les versions suivantes. La réalité est pourtant toute autre, puisque cette mise à jour a contribué au contraire à augmenter la taille des apps iOS. Et pas qu’un peu : pour certains apps, le poids a augmenté de 68 % en effectuant la compilation dans Xcode 14 au lieu de Xcode 13.
Les créateurs d’Emerge Tools, une série d’outils destinés aux développeurs d’apps mobiles, ont détaillé ce qui s’est passé dans un article publié sur leur blog. Puisque l’un des outils qu’ils proposent est pensé pour analyser le poids d’une app en quête d’optimisations, ils sont particulièrement bien placés pour analyser l’effet de Xcode 14 sur de nombreuses apps et pour comprendre ce qui s’est passé.
L’augmentation du poids des apps compilées avec Xcode 14 est la conséquence malheureuse de la fin du Bitcode, une idée lancée par Apple en 2015 que l’on pourrait résumer grossièrement ainsi. Au lieu d’envoyer sur les serveurs de l’App Store une app compilée prête à être installée, les développeurs envoient un Bitcode, un fichier qui contient en gros des instructions pour compiler la version finale. Ce n’est pas le code source de l’app, mais un intermédiaire qui aurait notamment permis à la firme de Cupertino de simplifier la transition 64 bits sur l’Apple Watch, sans faire appel aux développeurs.
Series 4 : la transition vers le 64 bits facilitée par Bitcode ?
L’avantage du Bitcode, c’est que l’app que vous téléchargez a été optimisée par Apple pour votre matériel. Parmi les optimisations réalisées sur ses serveurs, l’entreprise retirait notamment les « binary symbol », des fichiers de métadonnées qui sont indispensables pendant le développement et la compilation, mais inutiles dans le fichier final. L’air de rien, ces documents peuvent peser lourd et c’est ce qui a provoqué l’augmentation du poids des apps avec Xcode 14. Bitcode étant désactivé, les développeurs ont soumis des binaires finalisés à Apple et ces derniers n’étaient plus optimisés.
Dans le cas de l’app de Nike choisie en guise d’exemple, pas moins de 127 Mo supplémentaires sont liés à ces binary symbols qui n’ont pas été retirés dans la version finale. Ils sont particulièrement visibles dans les frameworks sous-jacents, puisque chaque élément a ses propres symboles et cela finit par peser particulièrement lourd sur le poids final de l’app.
Le site a analysé de nombreuses apps sur l’App Store et retrouvé des augmentations similaires dans de nombreux cas. Celle de Nike était la plus spectaculaire en termes de volume gagné à cause des binary symbols, mais ils peuvent avoir un impact bien plus léger… même chez Apple ! L’app Shazam, par exemple, a augmenté d’environ 2 Mo suite au passage à Xcode 14.
Pour les développeurs, l’article détaille comment configurer la compilation dans Xcode 14 pour retirer les binary symbols de l’app finale. La méthode recommandée est un script shell à ajouter au processus, juste avant la signature de l’app. Peut-être qu’Apple ajoutera une option plus simple pour le faire automatiquement, mais ce n’est pas le cas dans la version actuelle.
Apple n’a pas justifié l’abandon du Bitcode, si bien que l’on ne connaît pas ses motivations exactes. On sait néanmoins que cette idée aux multiples avantages théoriques avait aussi des inconvénients pratiques. Il y a plusieurs situations où utiliser le Bitcode n’était pas possible ou déconseillé et stocker les apps sur les serveurs de l’App Store dans ce format intermédiaire ne garantit pas autant leur pérennité qu’avec un binaire compilé.
Ces inconvénients n’étaient pas contre-balancés par des avantages aussi évidents que prévu et le format a finalement été bien peu utilisé par la pomme1. Tous ces éléments mis bout à bout ont probablement justifié l’arrêt de cette initiative, sept ans après son arrivée.
-
On n’est même pas sûrs que Bitcode a été vraiment utilisé un jour par Apple, l’entreprise n’ayant jamais communiqué sur le sujet. L’exemple donné plus tôt de l’Apple Watch Series 4 reste encore une hypothèse. ↩︎
C'est la faute d'Apple si des développeurs ne retirent pas les symboles de leurs apps ? 😳
Il faut donc qu'Apple prévienne, "attention, on ne le fait plus pour vous ?"
Rq: Ne pas retirer les symboles, c'est la porte ouverte à du retro-engineering pour les concurrents, ou d'autre, car ils donnent en clair les noms des fonctions internes, visibles en particulier lors de plantages, dans la pile des appels que la Console permet d'analyser.
On peut aussi avoir de bonnes raison de vouloir les garder.
Edit: Je préfère que mon code soit compilé par moi même plutôt que par Apple, car si ce n'est pas moi qui compile, alors ce que j'ai testé ne correspond pas à ce qui se trouve chez les utilisateurs. En effet, certaines options d'optimisation peuvent avoir dans des cas très particuliers des effets secondaires que je ne souhaite pas. De plus, si les optimisations ne sont pas les mêmes, les performances ou le timing précis de certaines opérations peuvent être différentes.
@marc_os
« C'est la faute d'Apple si des développeurs ne retirent pas les symboles de leurs apps ? 😳
Il faut donc qu'Apple prévienne, "attention, on ne le fait plus pour vous ?" »
Ben… quand c’est le cas du jour au lendemain après 7 ans… oui ?
c'est marc_os, donc c'est forcement la faute du dev, jamais d'Apple!
@ mimolette51
A part des attaques personnelles, tu as des arguments techniques à faire valoir ?
@mimolette51
Ça marche aussi très souvent dans l’autre sens 😅!
Apple c’est le grand méchant donc c’est toujours de sa faute 😅.
D’ailleurs j’ai loupé la cuisson de mon gâteau ce week-end … je me demande si c’est pas « un peu » la fait d’Apple quand même 😅
@cecile_aelita
Ça dépend, c’était une tarte aux pommes ?
@Derw
Même pas 🙃
Mais Apple étend son influence bien au delà des pommes 😜
@ Rez2a
Ça ne fait pas partie du travail d'un développeur/éditeur que de vérifier ce qu'il livre à ses clients, et de se poser des questions si un truc bizarre arrive avec une nouvelle version de Xcode ?
Pour info, quand un dev a des problèmes, il peut ouvrir des tickets chez Apple, il y a des forums dédiés. Quoiqu'il en soit si on se pose une question il y a des moyens d'avoir une réponse. Et si on n'en n'a pas on peut toujours venir râler, ici par exemple ou plutôt via Twitter.
Quoiqu'il en soit, vérifier ce qu'on livre au client, ça fait partie du B A BA du métier il me semble.
@marc_os
Et ça ne fait pas partie du travail d’Apple de prévenir les développeurs d’un changement comme celui-ci ? Si vous vous amusez a auditer chacun de vos builds pour vérifier si Apple n’a pas décidé de changer quelque chose sans vous le dire, grand bien vous fasse.
Manifestement, vous êtes plutôt une exception, cf. l’article et les apps qui ont été impactées, et c’est pas des petits noms…
Surtout que bon, on ne parle pas d’un problème flagrant comme un crash au lancement, perso je ne m’amuse pas à vérifier la taille de mes builds d’une version sur l’autre systématiquement. Ça peut très facilement passer inaperçu.
Ressentis au boulot où notre app a pris plus de 50mo du jour au lendemain
@ soucolline
Ils serait peut-être temps de retirer vous-même les symboles de votre app ?
(D'après l'article, c'est la raison de l'embonpoint.)
Ca devient n’importe quoi le poids des app:
Instagram : 258 mo
AirBnB : 223 mo
Gmail : 396 mo !!!
LinkedIn : 284 mo
Waze : 128mo
Uber : 357 mo !!!!
Et à côté :
Shazam : 23 mo
LeMonde : 31 mo
ViaMichelin 59 mo
..
Serieux c’est quoi ce merdier ?
Voilà pourquoi je ne met plus à jour mes apps.
C’est toujours plus lourd avec plus de pub.
@misterbrown
L’application de Samsung pour ma machine à laver quasi 500Mo 😂🙈
@fredsoo
🤦🏻♂️🤦🏻♂️🤦🏻♂️
@misterbrown
On voit toute la merde qu’ils mettent dans leurs applis
@misterbrown
J’ai un vieil iPhone avec peu de stockage (32 Go) du coup je regarde souvent ce qui prend de la place et à voir le poids de certaines apps on se demande comment ils se débrouillent…
Surtout à une époque où la majorité des opérations sont réalisées côté serveur, comme Google Maps.
Même des apps qui sont presque des web apps, comme Crédit Mutuel, arrivent à peser plus de 100 Mo, c’est ouf.
@laclouis5
J’avoue que j’utilise beaucoup les web app pour ça 🙂.
J’ai largement de la place sur mon iPhone, c’est pas la question 🙂(je dois être à 30Go de pris sur 64). Mais c’est surtout pour le principe … l’application YouTube qui se compte en centaines de megaoctet… juste pour lire des vidéos YouTube … là où un simple signet vers l’écran d’accueil de l’iPhone ne pèse que quelques kilo …. Pour une différence d’expérience utilisateur assez négligeable (en tout cas pour mon cas qui ne justifie pas de prendre des millions de fois plus de place 😅)
@misterbrown
C’est tellement vrai … mais oser dire que tu ne mets pas à jour ici … c’est la porte ouverte pour se faire lapider en place publique mon cher 😅🫣!
Devs de merdes des deux côtés (Apple et app) et on a des app qui font rien et qui passent le GB bientôt.
Apple doit régler ces problèmes, parce que on pourra pas compter sur ts les devs pour s’ en préoccuper.
Mais cette suppression du BitCode, à l'origine de l'embonpoint, est-elle accidentelle comme le suggère le titre de l'article (et le problème disparaîtra dès que le Bitcode aura été réactivé), ou est-ce une décision d'Apple, sans espoir de correctif?
@r e m y
C’est une décision assumée de la part d’Apple. Le Bitcode a été officiellement abandonné et c’est indiqué dans la documentation.
Ok merci. Donc le titre de cet article est trompeur.
Ce n'est pas accidentel. Éventuellement on pourrait parler de conséquence imprévue, mais pas d'accident... voire utiliser l'adverbe "incidentellement" car c'est bien un effet incident à cette décision d'abandon du Bitcode.
@r e m y
Oui et non 🤷♂️ la disparition du Bitcode est l’élément déclencheur, mais parce qu’avec cet outil Apple faisait une partie du boulot pour les développeurs.
C’est malheureux, oui. Mais il y a des moyens de rétablir la situation sans pour autant réutiliser le Bitcode
Certes mais ça n'a rien d'un "accident" vu que c'était prévu.
C'est juste une conséquence non anticipée par les développeurs.
Je suis surprise qu’il n’y ait pas encore eu de commentaires d’adepte des théories du complot pour dire que « Apple l’a fait volontairement pour saturer les iPhones avec de l’OBSOLESCEEEEEEENCE PROGRAMEEEEEE » 😂😂
Xcode.
A la fois super, et nul à chier.