Server-driven UI : mettre à jour une application mobile sans déploiement sur les stores

Déployer une mise à jour d’une application mobile sur un store n’est pas anodin : le délai est variable, l’utilisateur n’installera pas nécessairement la mise à jour… impossible de garantir qu’un utilisateur n’aura pas quelques versions de retard et donc des bugs qui nuiraient à son expérience.

Côté entreprise, ce déploiement serait trop long et complexe pour répondre au besoin de réagir très rapidement à une situation. Le server-driven UI vise à répondre à cette problématique en permettant aux applications mobiles d’évoluer rapidement sans avoir à déployer des mises à jour sur les stores.

J’ai découvert le server-driven UI à travers les retours d’expérience de Getaround et Zalando lors du salon MobileOne 2019, et vous propose ici une analyse de cette solution.

Le server-driven UI

 

Le client a des besoins exponentiels pour une équipe qui garde la même capacité – crédit : Zalando

Le server-driven UI n’est pas un framework, un langage ou une plateforme mais une architecture technique qui repose sur deux briques :

  • Des composants natifs dans l’application mobile ;
  • Une API à base de réponses JSON, la plupart du temps exposée par un serveur (le backend), qui fournit à la fois le contenu à afficher et sa structure.

C’est ce dernier point qui est très différent par rapport à une application mobile classique : en général l’affichage est géré par l’application, et les données sont fournies par le serveur. Dans le cas du server-driven UI, le serveur fournit les deux, et l’application se contente d’interpréter la structure pour l’afficher avec des composants natifs. L’utilisation de composants natifs est là aussi un critère déterminant car fournir les données et la structure est une technique connue : le HTML !

Alors, a-t-on réussi à réinventer quelque chose qui existe depuis plus de 20 ans ? Pas vraiment ! Car ici, le fait d’utiliser des composants dans le langage natif des plateformes permet d’obtenir une application qui respecte les « codes » visuels de ces dernières et les habitudes des utilisateurs. Ce ne sont donc pas des boutons qui « ressemblent », via un style CSS, à ceux de la plateforme mais de vrais contrôles bien intégrés !

 

Techniquement, ça ressemble à quoi ?

Nous l’avons vu, cette technique repose sur deux briques. Concernant l’application mobile, il faut créer des « composants » métiers natifs, par exemple avec Objective C, Swift, Java, Kotlin, etc. Certains composants seront généralistes : entête, liste, menu, quand d’autres seront plus spécifiques et complexes : utilisateur, voiture, article, basés sur des composants simples. Ces composants définissent leur affichage, voire certaines interactions (ex : navigation dans un carrousel d’images).

Il est aussi conseillé de mettre en place un design system, sorte de bibliothèque de composants visuels (pas de code, juste la façon de les afficher et les interactions possibles). Le but est d’avoir une homogénéité visuelle dans toute l’application et de pouvoir se reposer dessus pour créer les composants natifs.

La construction de l’API quant à elle est libre, mais doit forcément définir la structure de la page à afficher sous forme d’arborescence, ainsi que les données à afficher.

Exemple de fichier JSON simple pour l’affichage d’un entête et un titre – crédit : Getaround

 

Et dans la vraie vie, ça marche ?

En suivant cette approche, Getaround peut mettre à jour dynamiquement le contenu des pages de son application, sans que cela nécessite un déploiement sur les stores. Par exemple, l’ajout d’un nouveau type de véhicule a pu se faire très simplement, en exploitant un composant générique et en envoyant simplement un nom et une nouvelle icône à l’application via l’API du serveur. De la même manière, ils ont pu ajouter toute une nouvelle section sur les dimensions des véhicules, en utilisant des composants existants.

De son côté, Zalando a poussé le concept bien plus loin en créant sa propre plateforme dite « low-code », permettant, grâce à un logiciel développé en interne, de définir de manière visuelle le contenu des pages de son application.

Grâce à cette plateforme, la campagne de sensibilisation « Free to be more than my breast cancer » a pu être lancée en 3 jours, sans aucune release de l’application mobile, ni besoin d’ingénieur pour mettre au point les pages.

 

Les limites de la solution

Le fait de déporter la structure des pages côté backend n’élimine pas les développeurs Android/iOS ! En effet, ils sont nécessaires pour créer les composants natifs utilisés dans les applications mobiles. Toutefois leur métier évolue, et plutôt que de se limiter à de l’affichage de contenus, ils peuvent se concentrer sur les fonctionnalités natives des plateformes (ex : GPS, Bluetooth, etc.) et la création de composants réutilisables.

Par ailleurs, cette technique ne peut pas être la solution à tous les problèmes : si elle est totalement appropriée pour des pages proposant du contenu qui évolue souvent, comme c’est le cas dans le domaine de l’e-commerce, elle ne convient pas aux applications nécessitant beaucoup d’interactions avec l’utilisateur (gaming par exemple). Au sein d’une même application, il n’est pas non plus nécessaire de « piloter » l’affichage de toutes les pages via du server-driven UI : c’est par exemple totalement inutile pour la page de profil d’un utilisateur si celle-ci n’évolue pas, ou peu. Il faut donc l’utiliser à bon escient.

Pour finir, la mise en place du server-driven UI représente un investissement humain et financier important au départ pour créer tous les composants natifs et mettre en place l’API côté backend. Pour reprendre l’exemple de Zalando, la création d’un outil de conception visuelle des pages permet une meilleure industrialisation du processus, mais représente un coût supplémentaire.

Avec le server-driven UI, nous pouvons mettre à disposition plus rapidement les fonctionnalités dans des applications mobiles sans les mettre à jour. Son utilisation trouve tout son sens dans des applications de type e-commerce, car leur contenu évolue fréquemment, mais n’est néanmoins pas indiquée pour tous les cas d’usages. On notera enfin qu’il ne semble pas exister de solution clé en main pour mettre en place une architecture de server-driven UI : nous devons développer nos propres composants et prendre le plus grand soin dans la définition de notre API afin de correspondre au mieux aux contraintes métiers.

Pour aller plus loin