Reprenons le chemin de la modification à distance. Cette fois-ci, plutôt que d’envoyer des données plus ou moins enrichies comme on a pu le voir avec des solutions de Feature Flag ou de Server-Driven UI, regardons comment envoyer directement des algorithmes et même du code. Après tout, on peut tout envoyer via notre serveur, tant que notre application sait l’interpréter.

Interpréteur de code

L’idée serait d’avoir une brique logicielle au sein de l’application qui transforme quelque chose de très basique comme du texte en une suite d’instructions à exécuter. Ce pourrait même être directement du code. Un tel système apporterait beaucoup de flexibilité, car il permettrait de modifier plus profondément le comportement de l’application.

On pourrait par exemple modifier un algorithme, un calcul complexe. On pourrait complètement modifier l’apparence d’un composant. Voire même définir un tunnel d’écrans et de fonctionnalités. J’imagine par exemple une utilité pour explorer et tester, une sorte d’A/B testing boosté. 99% de l’application serait “stable” (le code est figé, livré à chaque mise à jour, ne change pas), et il y a ce nouveau tunnel, qu’on veut tester, et modifier souvent. Puis, dès que l’on a des réponses à nos questions, on enlève ce côté dynamique pour l’embarquer pleinement dans une mise à jour.

J’explore à voix haute, tout ceci est hypothétique : aujourd’hui, je n’ai pas travaillé avec un tel système. Pour autant, je trouve intéressant d’en parler, de voir les possibilités, et ce qui existe.

Et justement, lors de mes recherches, j’ai trouvé plusieurs dépendances que l’on peut ajouter à notre projet.

• Côté Swift, il y a Eval.
• Pour Kotlin, KtsRunner.
• En Dart, dart_eval.
• Pour Flutter spécifiquement, flutter_eval et Remote Flutter Widgets dont j’ai vu le nom passer plusieurs fois dans ma timeline Twitter.
• Du côté de React Native, javascript propose eval() et le constructeur new Function().
• On peut aussi imaginer se créer un meta-langage.

Selon le langage et le framework, on a accès à davantage de possibilités. flutter_eval et dart_eval permettent par exemple d’envoyer une classe entière en Dart ou un widget, et quasiment comme si on l’avait écrit directement dans le code du projet. C’est puissant et ça nous apporte beaucoup de flexibilité. À l’opposé, en Swift, Eval propose plutôt d’interpréter des expressions simples, et de faire du template.

Points d’attention

La grande flexibilité que peut apporter un tel mécanisme vient aussi avec des problématiques qu’il faut avoir en tête.

• Il y a le coût à considérer. Créer un interpréteur ou en intégrer un demandera un certain effort. Il faudra également le tester et confirmer le degré de confiance qu’on peut lui accorder.
• Il faut déterminer les limitations. Envoyer des expressions n’offre pas les mêmes possibilités que d’envoyer toute une classe complexe.
• Et, élément très important, la sécurité. On ajoute une surface potentielle d’attaque. Il est très facile d’intercepter une requête HTTP et de changer la réponse. Il ne faudrait pas qu’un attaquant s’en serve pour injecter du code qui lui permettra de réaliser des actions non autorisées dans l’application.

Au final, au vu de ces points, je me demande si ce type de mécanisme ne serait pas à restreindre aux équipes internes pour effectuer des changements et des tests rapidement, ou à destination d’employés via un store d’entreprise / des appareils appartenant à une même flotte. Mais dans ces cadres, la barrière des stores (Apple et Google) est absente, puisqu’on peut déployer et forcer les mises à jour plus facilement via des stores privés.

Ou peut-être qu’il faudrait restreindre à des éléments graphiques, qui ne contiennent pas de logique métier.

Je serais très curieux d’avoir des retours d’expérience pour compléter ma vision. Actuellement, je resterais sceptique : je vois peu d’usage justifié au regard des problématiques qui s’ajoutent et des autres options que l’on a à disposition pour modifier une application à distance.

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

• #1 Pourquoi
• #2 Remote config, Feature Flag & co
• #3 Backend for Frontend (BFF)
• #4 Server-Driven UI
• #5 Interpréteur de code
• #6 Over-the-air update (OTA)
• #7 Les ressources
• #8 En résumé, mes options

Hors-série :

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