Xcode 14 a accidentellement augmenté le poids de nombreuses apps

Nicolas Furno |

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.

Devinez la date de sortie de Xcode 14 uniquement avec ce graphique… (image Emerge Tools).

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 ?

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.

Analyse des frameworks de l’app Nike avec la dernière version compilée sous Xcode 13.
Et la même analyse avec la première version compilée sous Xcode 14 : les « String Table » qui se sont ajoutés un petit peu partout correspondent aux binary symbols.

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.


  1. 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.  ↩︎


avatar 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 ?"

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.

avatar Rez2a | 

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

avatar mimolette51 | 

c'est marc_os, donc c'est forcement la faute du dev, jamais d'Apple!

avatar marc_os | 

@ mimolette51

A part des attaques personnelles, tu as des arguments techniques à faire valoir ?

avatar cecile_aelita | 

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

avatar Derw | 

@cecile_aelita

Ça dépend, c’était une tarte aux pommes ?

avatar cecile_aelita | 

@Derw

Même pas 🙃
Mais Apple étend son influence bien au delà des pommes 😜

avatar marc_os | 

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

avatar Rez2a | 

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

avatar soucolline | 

Ressentis au boulot où notre app a pris plus de 50mo du jour au lendemain

avatar marc_os | 

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

avatar misterbrown | 

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.

avatar fredsoo | 

@misterbrown

L’application de Samsung pour ma machine à laver quasi 500Mo 😂🙈

avatar misterbrown | 

@fredsoo

🤦🏻‍♂️🤦🏻‍♂️🤦🏻‍♂️

avatar nicolaspatate | 

@misterbrown

On voit toute la merde qu’ils mettent dans leurs applis

avatar laclouis5 | 

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

avatar cecile_aelita | 

@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 😅)

avatar cecile_aelita | 

@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 😅🫣!

avatar hawker | 

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.

avatar r e m y | 

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?

avatar Nico_Belgium | 

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

avatar r e m y | 

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.

avatar Nico_Belgium | 

@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

avatar r e m y | 

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.

avatar cecile_aelita | 

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 » 😂😂

avatar geooooooooffrey | 

Xcode.

A la fois super, et nul à chier.

CONNEXION UTILISATEUR