Faites perdre du poids à vos Apps mobiles !
Avec l’accroissement des possibilités de stockage offertes par les appareils sous iOS, le poids de nos applications a fatalement suivi la même direction. Ce constat a été mis en lumière par un rapport de Sensor Tower. Entre 2013 et 2017, le poids du top 10 des applications de l’App Store a augmenté en moyenne de plus de 1000%.
Apple a d’ailleurs fait évoluer sa règle initiale sur la limite de poids maximal pour le téléchargement des applications via le réseau cellulaire, doublant cette limite en l’espace de deux ans pour l’établir à 200 Mo.
Malgré cette tendance “naturelle” du marché, réduire le poids des applications présente de nombreux avantages :
- réduction de la consommation de données sur les réseaux, permettant aux utilisateurs de télécharger plus rapidement leurs mises à jour (notamment dans le cas d’update obligatoire), mais aussi et surtout de contribuer à un numérique plus sobre et plus écologique
- optimisation de l’espace occupé par l’application dans la mémoire du téléphone
- baisse des coûts de maintenance technique : plus l’application est lourde, plus elle intègre de code et/ou de librairies tierces, source de coûts de maintenance (mais aussi de bug)
Aujourd’hui, un rapport du poids des applications existe déjà sur App Store Connect : grâce aux optimisations déjà actives par défaut sur votre projet, la taille de votre application se verra optimisée selon la plateforme cible. Ainsi, il peut être courant d’avoir une application plus lourde sur iPad ou sur un OS ancien que sur les derniers iPhone ou OS les plus à jour.
Ce rapport peut aussi être généré directement depuis Xcode lors du déploiement de l’application vers l’App Store.
Pour cela, une fois l’archive pour l’application créée, il suffira de l’exporter en application Ad Hoc, Development ou Enterprise et sélectionner les options suivantes. Le rapport de tailles détaillé (App Thining Size Report) sera alors fourni par avec les artefacts de l’application.
Il est toutefois possible d’aller plus loin dans ces optimisations ou de s’assurer de leur mise en place. Voici quelques pistes pour y parvenir sur iOS.
Principal levier : introduire le bitcode
Depuis iOS 9, Apple a introduit la notion de bitcode dans le flux de développements des applications iOS. Le bitcode est une représentation intermédiaire d’un programme compilé. C’est un format à mi-chemin entre le code source (Swift, Objective-C) et le code machine (0 et 1). Les applications iOS qui activent le bitcode vont être recompilées par l’App Store, une fois upload.
Mais que permet-il ?
À l’instar du slicing, qui va supprimer les assets qui ne sont pas destinés à notre appareil, le bitcode va permettre de supprimer le code compilé qui n’est pas utile pour l’architecture de notre appareil.
On peut ainsi espérer gagner jusqu’à 50%, sur la taille du binaire de l’application.
Mais les avantages sont bien plus nombreux ; en effet Apple va optimiser l’application (ce bitcode), mais il pourra à nouveau effectuer cette optimisation de façon automatique sans besoin de re-soumettre, lorsque des optimisations du compilateur (LLVM) sont effectuées. Ceux qui ne publient pas de façon régulière peuvent ainsi bénéficier des dernières optimisations. C’est également pour cette raison que le bitcode est obligatoire pour les applications watchOS et tvOS, afin de pouvoir optimiser régulièrement ces plateformes spécifiques.
Il y a cependant une contrainte majeure pour activer le bitcode sur iOS : toutes les dépendances utilisées par l’application doivent également l’avoir activé. Cela peut être problématique pour les dépendances propriétaires privées.
Swift 5 pour réduire le poids et la dette technique future
L’arrivée de Swift 5 en mars 2019 a permis au langage d’asseoir un peu plus son rôle prédominant dans l’écosystème iOS, cette version ayant introduit la notion de “stabilité binaire”.
Jusqu’à présent, les applications utilisant Swift souffraient d’une limitation importante : de par la jeunesse du langage, celui-ci n’était pas stable, il était en constante évolution. Afin d’éviter des problèmes de compatibilité entre versions, Apple avait décidé d’embarquer dans chaque application iOS, les binaires Swift utilisées par l’application (Foundation, etc.). L’inconvénient majeur de cette approche était le coût en termes de poids ; toutes les applications devaient embarquer plusieurs Mo de binaires Swift.
Avec Swift 5, le langage a été rendu stable. Ainsi, les applications n’embarquent plus les binaires Swift, elles peuvent utiliser ceux directement inclus dans iOS.
Cela veut également dire qu’une application compilée avec une certaine version de Swift sera compatible et pourra utiliser une librairie externe compilée avec une autre version de Swift.
On peut ainsi espérer gagner plusieurs Mo, avec un minimum de 5 à 7 Mo, voire plus si on utilise plusieurs librairies Swift.
Certaines applications peuvent ainsi réduire leur poids de près de 10%.
Assets
Les Assets Catalog ont été introduits il y a déjà quelques années avec Xcode 5 et iOS 7 (2013).
Elles permettent notamment de :
- décliner les ressources images selon le type d’appareil ciblé : par exemple, les écrans ayant une densité de pixel plus importante (iPhone X) se verront utiliser les images fournies en @3x tandis que les écrans à densité plus faible (iPhone XR) se contenteront des images en @2x.
- définir des zones redimensionnables sur certaines images : il est ainsi possible d’obtenir des fonds de bouton plus léger et adaptable à n’importe quelle taille
- bénéficier d’options de compressions selon les types de ressources.
Avec tous ces éléments combinés, l’App Store est capable de proposer des applications contenant uniquement les ressources destinées aux appareils concernés.
Malgré cela, il est important pour les éditeurs de s’assurer que seules les ressources réellement utilisées par l’application soient effectivement intégrées. En effet, Xcode et l’utilisation des Assets Catalog ne permettent pas de s’assurer que les ressources intégrées sont réellement utilisées par l’application.
On-Demand Resources
Pour un parcours en marge, lourd en ressources ou pour toutes les ressources peu utilisées, il est possible d’adopter des mécanismes de téléchargement des ressources à la demande.
Une implémentation simple est par exemple de lancer le téléchargement des ressources concernées avant d’afficher le parcours en question, ou encore effectuer ces actions en tâche de fond.
Pour les plateformes Apple, il est également possible d’adopter une solution spécifique : les “On-Demand Resources”.
Avec cette implémentation, l’éditeur peut créer un pack de ressources à soumettre sur l’App Store. Ces ressources ne sont alors pas intégrées à l’application, allégeant ainsi son poids. L’application pourra ensuite les récupérer séparément et par elle-même lorsqu’elle en aura besoin.
L’adoption des On-Demand Resources nécessitera toutefois du travail spécifique pour les plateformes Apple côté application, mais également côté serveur lors du développement. En effet, il faudra adopter les pré-requis d’Apple pour l’hébergement de ces ressources afin de pouvoir fonctionner comme l’environnement de production de l’App Store.
Ses avantages une fois l’application déployée sera toutefois indéniables :
- les ressources pourront être hébergées sur l’App Store
- le poids de téléchargement de ces packs de ressources sera optimisé avec les mêmes mécanismes que les Assets Catalog (s’ils sont employés)
- du lazy-loading sur les ressources : leur téléchargement n’est lancé qu’au moment opportun
se couple parfaitement avec les fonctionnalités uniquement actives lors d’achats in-app (exemple : un pack d’emoticones uniquement pour des utilisateurs ayant souscrit à un abonnement).
Optimiser le téléchargement différentiel en ne modifiant que les fichiers et dossiers nécessaires.
Lors de la mise à jour des applications, l’App Store effectue une comparaison entre la version installée sur votre appareil et celle que vous souhaitez installée, et crée un delta package. Ce paquet ne contient que les changements entre les deux versions et est donc optimisé pour avoir un poids le plus bas possible.
Pour tirer partie au maximum de cette fonctionnalité, il est recommandé de ne modifier que les fichiers et dossiers nécessaires, que ce soit le code en lui-même ou les assets. Ainsi un refactoring important qui n’apporte pas forcément de nouvelles fonctionnalités peut produire un delta package plus important. Il est donc préférable de garder ce type de modifications pour des mises à jour importantes qui, de toute façon, provoqueront un delta package important.
Effectuer un ménage dans ses dépendances tierces
Pour la plupart des applications, les dépendances concentrent l’essentiel de leurs poids.
Il faut se demander si l’on tire pleinement partie de chacune de ses dépendances ou si, tout simplement, on en a vraiment besoin.
Ainsi, si votre application n’effectue que peu d’appels réseaux GET, il n’est probablement pas utile d’intégrer une librairie réseau. iOS fournit énormément de ressources de ce côté qui ont fait leurs preuves.
La programmation réactive étant en vogue, il est probable que vous intégriez une des nombreuses dépendances qui implémente ce principe, tout en n’utilisant qu’une fraction de ses possibilités. Cela peut ainsi être l’occasion de passer à Combine, le nouveau framework d’Apple qui offre des fonctionnalités équivalentes (à condition de ne supporter que iOS 13 ou plus récent).
Ce ne sont que deux exemples parmi tant d’autres, mais il est intéressant d’appliquer le même raisonnement pour chacun des dépendances.
Ce travail d’optimisation des dépendances tierces permettra, outre la réduction de la taille de l’application, de réduire les coûts de maintenance engendrés par les mises à jour successives, les corrections de bugs ou failles de sécurité, ou tout simplement leur remplacement quand elles sont obsolètes.
Conclusion
Point d’attention au début de l’App Store et des applications, le poids des applications a été rapidement relégué en bas de liste dans la liste des priorités techniques. C’est pourtant un excellent indicateur de la saine gestion technique d’une application : une prise de poids significative de votre application se traduira souvent par une dette technique coûteuse et une augmentation de l’insatisfaction de vos utilisateurs.
L’optimisation du poids des applications mobiles peut ainsi être un excellent sujet pour marier les objectifs de satisfaction utilisateurs, de sobriété numérique et de réduction des coûts de maintenance technique.
Nous vous encourageons ainsi à mener une étude sur l’optimisation du poids de vos applications et à s’assurer que celui-ci n’évolue pas significativement à la hausse avec le temps.
FAQ
Comment réduire le poids d'une application iOS ?
Les principales méthodes pour réduire le poids d'une application iOS sont d'activer le bitcode qui permet d'optimiser le code compilé, d'utiliser Swift 5 qui évite d'embarquer les binaires Swift, et de suivre les rapports de poids fournis par App Store Connect et Xcode.
Qu'est-ce que le bitcode sur iOS ?
Le bitcode est une représentation intermédiaire du code compilé, introduite depuis iOS 9. Il permet à l'App Store de recompiler et optimiser l'application pour chaque architecture d'appareil, pouvant réduire jusqu'à 50% la taille du binaire. Il nécessite que toutes les dépendances de l'application l'aient également activé.
Pourquoi utiliser Swift 5 pour optimiser le poids ?
Swift 5 introduit la "stabilité binaire" qui permet aux applications de ne plus embarquer les binaires Swift mais d'utiliser ceux inclus dans iOS. Cela réduit significativement le poids de l'application et assure une meilleure compatibilité entre les différentes versions de Swift.
Comment suivre le poids d'une application iOS ?
Le poids peut être suivi via App Store Connect qui fournit des rapports détaillés. Il est également possible de générer un rapport de taille (App Thinning Size Report) directement depuis Xcode lors de l'export de l'application en mode Ad Hoc, Development ou Enterprise.