Mettre à jour une application mobile sans passer par les stores - #7 Les ressources

Des Feature Flag aux mise à jour par OTA, on est monté crescendo dans les possibilités de modification d’une app mobile à distance. Aujourd’hui, revenons sur quelque chose de plus simple. Tellement simple que l’on va enfoncer des portes ouvertes.

J’y ai pensé sur la fin, ça m’a sauté aux yeux : les ressources. Toutes ces petites choses dont l’application peut avoir besoin comme des illustrations, des cartes, des documents pdf, des sons, des vidéos, etc.

On peut les embarquer directement au sein de l’application. Elles sont donc téléchargées en même temps que l’utilisateur installe l’application - c’est un package, tout est inclus dans la boîte.

Il y a plusieurs avantages pour l’utilisateur. Il a tout, tout de suite. Dès le premier lancement. Aucun besoin de charger (et donc de faire patienter), les ressources s’affichent immédiatement. C’est également disponible pour une utilisation hors-ligne.

Mais de l’autre côté, cela implique que la ressource ne peut pas changer. Il faudra déployer une mise à jour que l’utilisateur devra installer. Le poids de l’app peut vite s’alourdir. Même si c’est moins le cas aujourd’hui, avec toujours plus de stockage et de data internet dans les forfaits, certains utilisateurs restent regardant sur le poids affiché dans la fiche du store.

Sans surprise, on a des solutions pour modifier les ressources - on est tout de même sur une série “sans passer par les stores”. Il suffit de les exposer sur un serveur, de les rendre téléchargeables. Selon nos besoins, on a d’ailleurs plusieurs options :

  • Ne rien embarquer dans l’application, tout est en ligne. L’application sera légère à l’installation, au détriment de chargements à prévoir au premier lancement / aux premières utilisations. Point d’attention, l’app n’aura aucune de ces ressources à son premier lancement si l’utilisateur n’a pas de réseau. Il sera limité.
  • Embarquer ET avoir les ressources en ligne. On mixe les avantages. Les ressources seront disponibles tout de suite, et l’utilisateur aura accès à des versions plus récentes lorsqu’elles changeront.
  • On peut créer une mécanique pour ne télécharger que les nouvelles versions de ressources, en envoyant au serveur la date du dernier téléchargement ou un numéro de version. Le serveur répondrait alors soit avec une nouvelle ressource, soit que rien n’a changé (réponse légère).
  • On peut ajouter une notion de fraîcheur, un délai pendant lequel l’application va considérer qu’elle n’a pas besoin de faire une requête vers le serveur pour (peut-être) récupérer une nouvelle version de la ressource.

Tous ces choix peuvent être appliqués différemment selon les ressources. On aura par exemple envie d’embarquer de base la carte des métros qui est utilisée par la majorité de nos utilisateurs, mais pas celles des bus de nuit, qui sera en téléchargement optionnel.

On décide en fonction de plusieurs critères. Quand est-ce que c’est utilisé (dès le début vs dans un écran lointain), à quelle fréquence (chaque utilisation de l’app vs peut-être une fois de temps en temps), combien d’utilisateurs sont concernés (tous vs seulement un petit segment).

Terminons par un autre enfoncement de porte ouverte. Une porte encore plus grande. C’est bientôt le week-end, on peut se faire plaisir. Les données, ce sont aussi des ressources.

Des mentions légales par exemple, ou un référentiel JSON. Hop, sur un serveur ! Et le changement devient possible sans mise à jour de l’application. Le référentiel peut être exposé statiquement par le serveur ou devenir un endpoint. Idem pour les mentions, qui pourraient même se transformer en une page HTML chargée dans une webview.

Et ce titre qui change souvent ? Pourquoi pas un peu de Remote config. La boucle est bouclée.

Bon week-end :)


Série d’articles Mettre à jour une application mobile sans passer par les stores :

Hors-série :

  • Accélérer le temps de review App Store d’une application iOS
  • Forcer la mise à jour d’une application mobile