Nous y sommes enfin, la solution ultime pour mettre à jour notre application mobile sans passer par les stores. Une mise à jour complète. Pas juste un élément, pas besoin de prévoir un flag ou une quelconque configuration, non, on change quasiment tout ! Et sans besoin de l’aval d’Apple et Google. Ni même d’une action des utilisateurs. Mais quelle est donc cette magie noire ?

Over-the-air update

Derrière l’acronyme OTA se cache un mécanisme pour déployer une mise à jour directement sur les appareils des utilisateurs. Pour comprendre la différence avec une mise à jour classique, rappelons les étapes de ce processus (simplifié).

• L’équipe développe une nouvelle version.
• Le build est envoyé sur l’App Store / le Google Play.
• Apple / Google prend le temps d’effectuer quelques vérifications.
• La nouvelle version est disponible sur l’App Store / le Google Play.
• Via le store, l’utilisateur installe la nouvelle version…
  • Manuellement : quand l’utilisateur aura décidé de le faire.
  • Automatiquement : quand le système aura décidé du “moment idéal” (Wifi, en charge, niveau de batterie).

On note qu’il y a deux étapes qui peuvent prendre du temps et qui ne sont pas sous notre contrôle : la vérification par les stores et l’installation par les utilisateurs. Regardons maintenant comment se déroule une mise à jour OTA.

• L’équipe développe une nouvelle version.
• Le build est envoyé sur le serveur OTA.
• L’application détecte et télécharge la mise à jour.
• L’application se lance avec la nouvelle version.

Il n’y a plus d’action extérieure. C’est l’application qui se met à jour elle-même, sans intervention des stores ou de l’utilisateur. Le temps nécessaire pour que les utilisateurs disposent de la nouvelle version peut être fortement réduit par rapport à une mise à jour classique.

Note : le moment exact où l’application se lancera avec la nouvelle version dépendra de la solution utilisée. Par exemple au prochain lancement de l’application, ou une mise à jour forcée en pleine utilisation.

Comment est-ce possible ?

L'Over-the-air update est devenu faisable avec des technologies cross-plateform comme Flutter et React Native. Eh oui, autant le dire tout de suite au risque d’en décevoir quelques-uns, ce n’est actuellement pas possible de le faire sur une application native Android ou iOS.

Dans une application native, l’ensemble du code est figé lorsque l’on génère un exécutable, une version. On ne peut pas apporter de modification sur ce code, à moins de générer un nouvel exécutable et de l’installer. D’ailleurs, ce code est écrit dans un langage prévu par la plateforme. Par exemple Swift pour iOS et Kotlin pour Android. Il est naturellement compris par la plateforme - il n’y a pas besoin de le traduire.

Flutter et React Native fonctionnent différemment. On utilise les langages Dart et Javascript - il y a donc besoin de traduire pour que l’éco-système natif puisse comprendre les instructions. C’est le rôle des machines virtuelles qui sont embarquées avec ces technologies cross-plateform, une couche supplémentaire qui a la capacité d’exécuter ces langages et de discuter avec la plateforme native.

C’est grâce à cette différence que l’OTA est possible. Vu qu’il est possible d’interpréter du code au runtime, il suffit de récupérer du code distant (sur un serveur) qui serait utilisé à la place du code local (embarqué dans l’application). Bien entendu, c’est plus complexe que cela - les créateurs de Shorebird ont par exemple dû modifier le moteur de Flutter.

Et justement, en parlant de solutions, en voici trois disponibles :

• Shorebird pour Flutter.
• EAS Update pour React Native, par Expo.
• CodePush pour React Native, par Microsoft.

Tout, ou presque

L'Over-the-air update apporte une énorme flexibilité puisqu’il est possible de quasiment tout changer, sans même avoir eu à prévoir que nos composants soient configurables à distance. On peut changer du code métier, des composants graphiques, des dépendances, des images. La plupart du temps, c’est tout ce qu’il nous faut, pas besoin de plus.

Il faut tout de même être conscient des limitations. Certains morceaux de notre application ne peuvent pas changer. C’est par exemple le cas du code natif. Souvenons-nous, ce code est figé, il n’est pas interprété par la machine virtuelle qui fait tourner la technologie cross-plateform. Il ne peut être changé à distance.

Cas d’usage

L’utilisation la plus évidente, et qui apporte aussi le plus de valeur, est la correction d’un problème critique en production. Il y a un crash au lancement ? Le tunnel d’achat ne fonctionne plus ? Impossible pour les utilisateurs de se connecter ? On pourrait imaginer tout ce qui est vital pour l’application, et l’entreprise qui est derrière.

Avec une mise à jour OTA, on a la capacité de réagir très vite. On pousse un correctif, voire on rollback vers une version antérieure qui n’avait pas de problème, tout simplement. Comme je le disais dans mon article autour de Cynefin pour adapter nos réponses en fonction de la complexité, on a besoin d’agir maintenant. On prendra le temps d’apporter une meilleure réponse plus tard.

En dehors de la gestion de crise, on peut imaginer des cas pour tester en production. Afin de voir l’usage d’une nouvelle fonctionnalité. Ou de s’assurer qu’il n’y a aucun problème avec cette nouvelle version - on pourra rollback rapidement (voire automatiquement) s’il y a un souci. À surveiller si les solutions proposent de faire un déploiement progressif, ou de la segmentation. Ces cas d’usages seront davantage intéressant.

Une équipe qui voudrait s’approcher du déploiement continu pourrait être intéressée par des mises à jour OTA. Elle pourrait envoyer une nouvelle version toutes les heures en production par exemple.

Coût

Abordons maintenant la question du coût (argent et temps) d’un tel système. Je vais commencer par le coût en entrée, c’est-à-dire, l’investissement que l’on doit faire la toute première fois pour mettre en place de la mise à jour OTA sur notre application. Bonne nouvelle, le coût est très faible. On configure facilement et rapidement de l’OTA sur une application, y compris une déjà existante.

Côté Flutter, tout se passera par l’outil en ligne de commande que l’on doit installer et un petit fichier de configuration. Aucune modification à apporter au projet. Côté React Native, Expo est devenu le framework de référence, il est donc très probable qu’il soit utilisé sur le projet. Si c’est le cas, utiliser EAS Update reviendra également à une simple configuration. Sinon, il faut migrer le projet vers Expo mais là aussi c’est assez simple (et Expo propose d’ailleurs un outil de migration automatique).

Vient ensuite le coût du service. Shorebird et Expo ont tout deux un tier gratuit, qui permet de tester la solution, et qui est suffisant lorsque l’on a une petite application ou que c’est pour un usage interne. Avec une plus grande base d’utilisateurs, on doit passer sur des plans payant mensuellement. Et le prix change en fonction du nombre de mise à jour OTA installée dans le mois.

À noter que Expo propose un tier “on-demand” où l'on paie uniquement en fonction de l’usage réel - un plan qui est donc gratuit chaque mois où l’on ne fait aucune mise à jour. Je trouve cela très intéressant pour s’ajouter un filet de sécurité sans coût, et de pouvoir le déclencher au moment où il apportera une réelle valeur. Il existe également la possibilité de self-host le service EAS Update.

Le coût est cependant à relativiser. Il ne faut pas le regarder seul, il faut le contextualiser avec la nature de l’application et les pertes possible d’un mal fonctionnement. Si je m’appelle Uber et que mon app ne fonctionne plus, chaque heure compte. Chaque minute même. Les utilisateurs qui ont besoin d’un VTC ne vont pas attendre que ça se répare, que ça soit déployé sur les store, qu’ils l’installent, etc. Ils en ont besoin maintenant, et ils vont aller voir ailleurs. La course est donc perdue, l’argent entrant aussi.

Je ne connais pas le chiffre d’affaires d’Uber par heure, mais j’imagine qu’il est très élevé, et que si on le compare au coût du service, c’est très négligeable. C’est cela que je veux dire par relativiser. Dans l’absolu, le coût de faire une mise à jour par OTA à 200.000 utilisateurs peut paraître élevé, mais mis face au manque à gagner de plusieurs heures voire journées, on obtient un regard différent. Le potentiel chiffre que l’on peut sauver est bien supérieur au coût du service.

Et c’est autorisé ?

En voilà une bonne question. Une solution qui s’apparente à de la magie noire est sûrement interdite par Apple et Google. Eh bien non, il y a un cadre dans lequel on peut faire des mises à jour par OTA. Les solutions comme Shorebird et EAS Update ont été construites pour respecter les règles de l’App Store et du Google Play.

Il est en effet autorisé de télécharger du code s’il est exécuté dans une machine virtuelle ou par un interpréteur. Ajouter ces solutions à notre application n’ajoute donc pas de risque de se faire rejeter une soumission.

La contrainte principale sera sur le contenu de la mise à jour : elle ne doit pas être déceptive pour l’utilisateur. En d’autres termes, l’application doit continuer de faire ce qui est affiché sur sa page store et doit éviter de changer radicalement.

[Google Play] An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play’s update mechanism. Likewise, an app may not download executable code (such as dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser).

[App Store] 3.2.2 … interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store, (b) does not create a store or storefront for other code or applications, and (c) does not bypass signing, sandbox, or other security features of the OS.

La mise à jour par OTA est donc une réelle carte à considérer pour se donner davantage d’options et mieux s’adapter aux imprévus.

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