Les apps les plus populaires ont un problème d'obésité
En l'espace de quatre ans, le poids cumulé des 10 apps iOS les plus installés aux États-Unis a été multiplié par 11. Il est passé de seulement 164 Mo à pas moins de 1,8 Go. Depuis 2013, SensorTower a observé cette évolution qui voit des apps devenir sans cesse plus obèses et où même les meilleurs élèves — Spotify et Messenger — sont devenus six fois plus lourds sur cette période !
Le champion dans cette progression est Snapchat, 51 fois plus gros qu'à l'origine (203 Mo contre 4 Mo), suivi par Uber (22x) ou encore Gmail (20x). L'analyse porte sur le poids de la partie exécutable de l'application, pas sur ses dépendances ou les contenus qu'elle peut encore télécharger par la suite.
Le plus gros du lot reste néanmoins Facebook avec 338 Mo sur la balance, alors même qu'il utilise la technique de l'app slicing d'Apple, où ne sont téléchargées que les ressources nécessaires à un iPhone ou un iPad (lire Facebook : le Microsoft Word des temps modernes. SensorTower fait remarquer que la bride a été lâchée en 2015 lorsqu'Apple a passé de 2 à 4 Go le poids maximal autorisé pour une app et le phénomène s'est accru après iOS 10.
Facebook, à travers son app principale ainsi qu'avec Messenger et Instagram est bien représenté dans cette liste. De même que Google grâce à Gmail, Maps et YouTube. 6 de ces 10 apps viennent de chez eux. Deux facteurs peuvent expliquer cette course au poids : l'ajout continuel de fonctions et le peu d'efforts consentis pour optimiser le code.
Pourquoi se lancer dans de tels chantiers de nettoyage du code alors que les iPhone finissent toujours par augmenter leur capacité de stockage minimale et qu'ils gagnent en puissance de manière franche, gommant ainsi les possibles effets de lenteur de ces mastodontes.
iOS 11 contient plusieurs nouvelles options pour limiter le poids de ces apps sur votre espace de stockage. Toutefois ces réglages visent avant tout les logiciels dont on se sert peu, pas ceux que l'on utilise tous les jours.
Dans la version révisée, le mois dernier, de ses guidelines pour l'App Store, Apple demande aussi aux éditeurs de nettoyer leurs apps de tout code et frameworks qui n'ont plus lieu d'être, parce que dépassés ou rendus caducs par ses soins. À voir si cela peut avoir un quelconque effet et si Facebook et Google auront envie de faire le moindre effort.
@Applesoft
64Mo pour moi, et seulement 18Mo si on ne compte pas les données comme les caches etc
@Applesoft
81 eme sur 151 applications chez moi !
Elle prend 70mo...
Je suis étonné qu'Apple ne soit pas plus stricte avec le poids des app.
Stev... Nan.
@DouceProp'
"Stev... Nan."
La phrase que doit se dire Tim Cook avant chaque prise de décision ;-)
You made my day ?
@DouceProp'
Tout ca a cause des jeux.
si on prend un Iphone 128go on s'en tape non de toute cette histoire ?!
ca reviens un peu a dire,
je fais mon déménagement j'ai 3 mètre² d'affaire, j'ai une pièce de 60 m², je peux tout balancer en vrac dedans, ca rentrera bien :-)
mais avec un peu de rangement on s'y retrouve bien mieux et ca permet de mieux voir venir la suite ;-)
Le poids des applications devient vraiment honteux. Qu'un jeu (3D) fasse 300Mo pourquoi pas, mais Facebook???
Tout ça pour afficher des images, vidéos et quelques commentaires? Comme sur une simple page web en fait - rien de plus extraordinaire - ah mais si si ! Regardez moi toutes ces belles pub qui vous pourrissent l'écran .. ça c'est une belle innovation qui mérite sa mise à jour.
D'ailleurs, je ne fais maintenant que les mises a jours dites majeures et plus celle qui arrivent comme ça toutes les x semaines - juste pour dire - "amélioration" etc. ou alors écrire un message "fun" dans l'app store ex: leboncoin..
Et puis franchement, ce n'est vraiment pas écologique non plus tout ça! On a suffisamment chaud comme ça, alors cher développeurs, laissez tous ces serveurs au repos.
C'est pas celui qui a la plus grosse (App) qui est le meilleur... hein?
@5ebastien :
"Et puis franchement, ce n'est vraiment pas écologique non plus tout ça!"
C'est toute la logique Apple : "Nous alimentons tous nos Apple Store grâce à des sources d'énergie renouvelables", mais de l'autre côté, ils ne font aucun effort pour forcer les delta updates sur l'App Store (télécharger uniquement la partie de l'application qui a été modifiée); et pour faire une mise à jour mineure d'une application système comme Musique ou Safari, il faut télécharger une nouvelle version d'iOS qui pèse 1 Go.
Non, télécharger plusieurs centaines de Mo par application et par appareil iOS dans le monde, ça ne consomme rien du tout...
@ sachouba
Je suis certain que le delta update arrivera sur iOS d'ici peu.
Je ne dirai pas qu'Apple copie Android, mais plutôt que les bonnes idées se répendent (XCode 9 offre le debug wifi).
Le delta-update ce n'est pas une idée nouvelle. Mais elle devient nécessaire. Google l'a fait pour une autre raison : les pays en voie de dev ou le cell est le seul lien vers l'internet et la necessité de reduire l'usage data, pays ou Apple est beaucoup moins présent.
C'est déjà le cas depuis iOS 6 / 7.1:
"Starting with iOS 6, the app store will automatically produce an update package for all new versions of apps submitted to the store. When generating the update package, the app store compares one or more prior versions of your app to the new version and creates an optimized package for each that contains only the content that has changed between versions of your app, excluding any content that did not change. This comparison looks at everything in the application bundle, including the application executable, nibs, localizations, image files, video files, audio files, text files, and files containing data in a custom format."
"For devices running iOS 7.1 and later, the update package may include only the differences between the old and new versions of a changed file instead of the full file. This may significantly reduce the size of the update package in the case where only a small part of a large file changes, but will increase the update's installation time on the device."
(Technical Q&A QA1779)
La taille affichée ne correspond pas en revanche à la taille réelle de la mise à jour, mais à la taille maximale de la mise à jour, d'où la confusion de la plupart des gens ici. De plus, si le téléchargement est plus rapide qu'avant, l'installation, elle, est plus longue.
D’ailleurs je ne sais pas si c’est un bug mais la taille des mises à jours d’app sur iOS 11 n’est plus indiqué (sur iPad en tout cas)
Un des facteurs (le principal selon moi) de prise de poids des apps est du à ... Apple.
En effet le passage à Swift impose d'ajouter libswiftCore.dylib qui fait plus de 30Mo avant le slicing.
Du coup une app Objective-C qui faisait 3-4 Mo réécrite en Swift passe à presque 35 Mo soit x11 sur la taille.
Mais c'est plus facile de dire dans les comms que les devs ne savent plus faire leur travail ;-)
@mhausherr
Un des facteurs oui, principal certainement pas.
Une fois le slicing fait Swift ajoute actuellement 7Mo a une application (Overcast est passée de 4Mo à 11Mo, PCalc a gagné 7Mo aussi : https://mobile.twitter.com/jamesthomson/status/859491714502995970).
Ça n'excuse pas les 350 autres Mo que Facebook a pris par ailleurs…
Donc oui ça sera chouette quand l'ABI de Swift sera stable et que les x fois 7Mo seront retirés des applications (iOS12 ou 13, avec Swift 5 ou 6), mais ça ne résoudra certainement pas le problème.
La bonne nouvelle, c'est que je n'utilise aucune de ces 10 apps. You shall not paaaaaassssss (through me)
Difficile de reprocher aux développeurs de ne pas optimiser leur code, tant cela a toujours été la règle (du moment que les ressources sont disponibles, pourquoi faire l'effort ?). Par contre, on se rend compte que les possesseurs d'iPhone dont le stockage est limité à 8 ou 16 GB sont fortement pénalisés par cet état de fait, et donc que les arguments de certains de type « pas besoin d'avoir une grande capacité de stockage, il suffit d'utiliser le cloud » ne sont pas très pertinents...
Cordialement,
HAL1
@ webHAL1
Sur iOS il faut deja optimiser, plus que sur Android.
Les iPhones ont beaucoup moins de mémoire que sur Android, il faut donc faire attention avec les ressources pour les applis multi-platform.
@webHAL1 :
C'est tout le contraire ! Là où Android est proposé sur des appareils très bas de gamme dans les pays émergents, dont certains sont équipés de 512 Mo de RAM et 4 ou 8 Go de stockage encore aujourd'hui, iOS n'est proposé que sur des appareils haut de gamme ou anciennement haut de gamme.
Les possesseurs d'iPhone dans les pays émergents ont, en sus, plus de moyens que les possesseurs d'un smartphone Android entrée de gamme, qui doivent se contenter d'un forfait avec très peu de data et en 2G.
Les apps se doivent d'être optimisées pour fonctionner hors ligne, sur des réseaux instables, en 2G, en utilisant très peu de données, le tout sans remplir le stockage ni la RAM... Sinon elles ne sont tout simplement pas téléchargées.
Quand on pense qu'il existe un Facebook Lite qui ne pèse presque rien, conçu initialement pour les pays émergents et les smartphones poussifs d'entrée de gamme sous Android, on voit que la programmation allégée existe bel et bien.
https://www.facebook.com/lite/
En revanche pas de Facebook Lite iOS...
@Mike Mac :
Effectivement, j'utilise Messenger Lite, qui pèse 17 Mo sur mon smartphone (5 Mo au téléchargement) au lieu de plusieurs centaines de Mo, et qui est bien plus rapide et moins consommateur de batterie également.
Un utilisateur m'a indiqué une fois qu'une de mes applications ne devait pas être bien compliquée à faire puisqu'elle ne pesait pas beaucoup comparée à d'autres !
Pour moi le vrai problème c'est que l'OS est de plus en plus riche (plus de fonctions intégrées) et malgré ça, les applications sont de plus en plus grosses!
En gros, si on remplace les fonctions des bibliothèques tierces par des appels systèmes, on peut se passer des bibliothèques!
Perso, je fais du développement Java, et des lib comme Apache commons-io commons-lang etc font aussi le boulot: depuis le passage à Java 1.7 minimum, les méthodes qui doublonnent les API de base sont vides (juste l'appel à la méthode système) et dépréciées (avec le commentaire expliquant qu'il faut utiliser la méthode système!)
Donc même sans mettre à jour mon code, l'application de réduit car la lib tiercé est plus petite.
@rolmeyer
Je confirme, c'est possible ?
Une des causes du surpoids est lié à Swift pour 2 raisons :
- instabilité de l'ABI, donc chaque app doit inclure la runtime de Swift (<10Mo)
- une dépendance contenant du Swift doit obligatoirement être packagée dans une librairie dynamique (et non statique). Du coup, le code non utilisé de la librairie est quand même embarqué et non "cleané" à la compilation.
Du coup, plus une app va avoir de dépendance écrite (en partie ou entièrement) avec du Swift (ou découpée en module contenant du Swift), plus son poids va exploser.
Simplicité, efficacité, optimisation, un travail de programmation sans cesse renouveler. Depuis pas mal d'année Apple y travail. C'est dans son ADN, même dans sa communication, son design produit, ses iOS et OS.
Mais je pense que les apps maisons eux aussi ont pris du poids!?
Il y a un problème structurel qui est de la responsabilité d'Apple.
Bien que ce ne soit pas impossible, Apple ne facilite vraiment pas la tâche des devs pour ce qui est de créer et intégrer des librairies ou frameworks statiques. C'est la misère. L'avantage d'une librairie statique est qu'au moment d'assembler l'executable final, monolithique, il est possible de retirer tous les fragments de code inutiles. Ce n'est évidemment pas possible avec des librairies dynamiques (en fait si, mais il faut de l'outillage qu'Apple ne fournit pas, évidemment).
Le partage d'une même librairie entre plusieurs apps, pour éviter des duplications inutiles, n'est pas non plus franchement très populaire chez Apple, ni sur iOS ni sur macOS.
Qu'Apple commence par améliorer leurs outils et l'infrastructure d'exécution ! Ce n'est pas aux développeurs tiers de faire le boulot d'Apple.
Pages