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 :

• #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

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

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

Peu importe le framework utilisé (“je fais du natif iOS”, “je fais du cross-plateforme Flutter, React Native”), et quelque soit le type de poste (“j’archive avec mon macbook”, “c’est le runner de ma CI qui archive”), on n’y échappe pas.

Cette mécanique imposée par Apple n’a pas son équivalent côté Android ou sur le web. Pas étonnant que ça provoque quelques maux de têtes au premier contact. Ça arrive même à des développeurs iOS plus expérimentés. Mais comme tout, ça s’apprend.

Une fois que l’on a compris les rouages, on est beaucoup plus à l’aise pour résoudre les problèmes qui gravitent autour de la distribution d’applications iOS. Et c’est là que j’interviens aujourd’hui. Je vais vulgariser certains concepts de base pour, je l’espère, permettre de mieux comprendre les problèmes qui surviennent et trouver plus facilement des solutions.

Je démarre en douceur, en grattant un peu la surface, ce qui est visible par tous. On plongera en profondeur et avec un peu plus de technique ensuite. Ça va bien se passer.

Les canaux de distribution

Regardons tout d’abord les différentes possibilités à notre disposition pour utiliser une application iOS que l’on développe soi-même, et les spécificités de chacune d’elles.

• Simulateur

Depuis mon poste, je peux installer l’application en cours de développement sur un simulateur et l’utiliser comme bon me semble. C’est ce qu’un développeur fait en continu. C’est rapide, on peut debugger.

• Appareil

Depuis mon poste, je peux installer l’application en cours de développement sur un appareil relié à ma machine (câble ou WiFi). C’est ce qu’un développeur va faire également pour tester l’application sur un vrai appareil. On peut également debugger. L’application expire au bout d’un temps.

• Store de bêta alternatif

Je peux distribuer une version bêta de mon application sur des stores comme Firebase Distribution, Appaloosa, App Center. C’est ce que l’on utilise souvent pour déployer en continu les incréments réalisés, pour que l’équipe interne puisse installer les différentes versions de l’application sur leurs téléphones.

Il faut enregistrer l’UUID de chaque appareil (maximum 100) et inviter l’utilisateur sur ce store alternatif. L’application expire au bout d’un temps.

• TestFlight (interne)

Je peux distribuer une version bêta de mon application sur TestFlight en mode “tests internes”. C’est une alternative intéressante aux stores bêta alternatifs car avec TestFlight, on ne s’embête pas à enregistrer des appareils.

Il faut seulement inviter les utilisateurs sur TestFlight, avec un maximum de 100 personnes. L’application expire au bout de 90 jours.

• TestFlight (externe)

Je peux distribuer une version bêta de mon application sur TestFlight en mode “tests externes”. C’est LA solution pour faire des tests à grandes échelles avec des utilisateurs externes. Il suffit de les inviter ou de leur donner un lien pour qu’ils rejoignent le test.

On peut monter jusqu’à 10.000 personnes. Apple effectue une revue de l’app à chaque nouvelle version. Petit avantage intéressant, on peut passer une version directement en prod (App Store) si on est satisfait.

• App Store

Je peux distribuer l’application finale sur l’App Store. Tous les utilisateurs y auront accès, sans contrainte, limite ou enregistrement à effectuer. C’est la prod ! C’est par l’App Store que les utilisateurs classiques découvrent et installent toutes leurs applications.

• Store de prod interne

Je peux distribuer l’application finale sur un store interne à mon entreprise. C’est l’option que l’on va choisir si on veut déployer une application réservée à ses salariés - elle doit rester privée, on veut contrôler qui peut l’installer.

Un exemple : les vendeurs d’une grande enseigne qui auraient une application spéciale sur leurs iPads pour gérer les stocks du magasin et la caisse. On ne veut pas la voir sur l’App Store. L’application expire au bout d’un temps.

• Store de prod alternatif

Je peux distribuer l’application finale sur un store alternatif. J’en parlais dans le récap des news autour des applications mobile, Apple va permettre la création d’autres stores pour installer des applications de production. Je ne m’étalerais pas plus sur ce sujet ici, c’est encore trop récent, je n’ai pas toutes les informations.

J’ajoute une précision. Quand je dis “l’application expire au bout d’un temps”, c’est à cause des Provisionning Profiles ou d’une limite spécifique au canal de distribution. On peut obtenir une application qui “n’expire jamais” si on pousse des nouvelles versions avant les dates limites.

Les types de distribution selon Apple

Descendons d’un cran en profondeur, je vais commencer à utiliser des termes techniques d’Apple. On a vu qu’il y avait beaucoup de possibilités pour installer une application iOS, mais Apple les regroupe selon 4 types de distribution. Ces termes seront utiles pour créer les bons Provisionning Profiles.

• Development. On installe l’application directement sur un appareil, et celui-ci doit être relié à un Mac.

• Ad-Hoc. On archive l’application (on crée un binaire) afin de le distribuer sur des stores de bêta alternatifs (Firebase, Appaloosa, App Center, …).

• App Store Connect. On archive l’application afin de la distribuer sur les stores officiels d’Apple (App Store et Test Flight).

• In-House. On archive l’application afin de la distribuer sur un store de production interne.

J’en profite pour également introduire la notion de Certificate. On va se pencher sur les deux types qui sont intéressants dans notre cas.

• Development. C’est utile lorsque l’on veut signer l’application pour l’installer directement sur un appareil.

• Distribution. C’est utile dès lors que l’on veut signer l’application pour la distribuer, peu importe comment (Ad-Hoc, App Store, In-House) et où (store de bêta, App Store, TestFlight, store interne, …).

À noter qu’il existe ces mêmes types pré-fixés par “iOS” ou “Mac”. C’est la même chose, sauf qu’ils contraignent à leurs plateformes.

Les ingrédients

Maintenant, entrons dans le vif du sujet, allons dans la profondeur. La page ressources du compte développeur regroupe tous les éléments nécessaires pour distribuer une application. On y retrouve ceux qui sont existants, expirés, et on peut en créer de nouveaux.

Tous ces éléments sont créés sur notre compte développeur, ce qui a deux conséquences. Ils peuvent servir à toutes les applications sous la propriété de ce compte - cool. Les limites de création concernent l’ensemble du compte, ce n’est pas par application - pas cool.

• Devices

C’est la liste des appareils enregistrés sur notre compte développeur. Il est nécessaire d’ajouter ici l’UUID d’un appareil sur lequel on souhaite installer l’application en direct ou distribuer sur un store de bêta (donc des distributions de type Development et Ad-Hoc).

La limite est de 100 appareils (pour tout le compte !). Je n’ai qu’une seule occasion par an de supprimer des appareils : le mois précédant la date anniversaire de la souscription au Apple Developer Program. Apple nous le rappelle quand on approche de cette période.

• Identifiers

Chaque application possède un identifiant unique sous la forme com.example.app qu’il faut enregistrer dans cette section. On y associe également des Capabilities - des autorisations d’utiliser certains services (Push Notifications, HomeKit, Siri, …).

Pour une même application, on peut être amené à créer plusieurs Identifiers. Par exemple pour différencier des environnements (com.example.app et com.example.app.staging). L’intérêt sera de pouvoir installer les deux applications sur un même téléphone.

• Certificates

Dès que l’on veut installer une application sur un appareil ou la distribuer, il faut signer l’archive (le binaire) de l’application. C’est là qu’entre en jeu le certificat. Il indique que cette application provient de notre compte.

En général, chaque développeur crée son certificat de type Development, afin de pouvoir installer l’application en cours de développement sur son appareil. Et il faut au moins générer un certificat de type Distribution pour déployer l’application sur des stores.

Un certificat est lié au compte développeur, et non à une application - un seul certificat de Distribution peut donc signer toutes nos applications. D’ailleurs, on est limité à un maximum de 3 certificats de type Distribution. Il sera intéressant d’en générer un second lorsque l’on s’approche de la date d’expiration du premier. Ou parce que l’on veut le donner à une équipe externe et pouvoir le révoquer facilement sans nous impacter.

Attention, on ne peut télécharger le certificat contenant la clé privée de signature qu’au moment de sa création. La machine qui signe les applications doit avoir le certificat avec la clé privée dans son keychain.

Un certificat expire au bout d’un an. Une application ne se lancera pas si le certificat associé est expiré ou invalide. Il faudra distribuer une nouvelle version avec tous les éléments valides. L’App Store n’est pas concerné par ce problème.

• Provisioning Profiles

Un profil est la glu qui lie tous les éléments. On associe un Identifier, un Certificate, un type de distribution et on sélectionne des devices. Le profil permettra d’indiquer à l’appareil si l’application peut être installée et à quels services elle a accès.

On en crée autant qu’il y a d’applications, de type de distribution (Development, Ad-Hoc, …) et d’environnement (si on a plusieurs Identifiers). On se retrouve rapidement à en avoir une grande quantité.

Un profil expire au bout d’un an, et devient invalide si le certificat auquel il est associé expire. La machine qui compile l’application doit avoir les bons profils installés.

Une application ne se lancera pas si le profil associé est expiré ou invalide. Il faudra distribuer une nouvelle version avec tous les éléments valides. L’App Store n’est pas concerné par ce problème.

• API Keys

Bonus. La clé d’API permet de s’identifier auprès d’Apple pour utiliser des services de l’App Store Connect. Ce sera utile pour les runners d’une CI lorsqu’une commande interagit avec le compte développeur (ex: récupérer un profile) ou avec l’App Store (ex: soumettre une application).

La génération des clés d’API se fera sur l’App Store Connect, onglet Users and Access, et non depuis le compte développeur.

La mayonnaise

On a tous les ingrédients nécessaires pour faire monter une belle mayonnaise, il n’y a plus qu’à les assembler. Je vais illustrer avec plusieurs scénarios qui peuvent arriver tout le long d’une année.

• On commence une nouvelle application

On enregistre un Identifier pour notre application et on ajoute les différents appareils de l’équipe dans Devices. Chaque développeur génère son Certificate (Development) puis on crée un Provisioning Profile (Development) (associant les appareils de l’équipe et les certificats des développeurs).

Pour pouvoir déployer les incréments sur un store de bêta, on génère un Certificate (Distribution) puis un Provisioning Profile (Ad-Hoc) en cochant bien tous les appareils de l’équipe.

Pour pouvoir déployer sur TestFlight et sur l’App Store, je vais créer un Provisioning Profile (App Store). On a déjà le bon certificat.

• Un certificat expiré

On génère un nouveau Certificate du même type puis modifie tous les Provisioning Profiles qui étaient associés à l’ancien certificat pour sélectionner le nouveau.

• Un profil a expiré ou est invalide

On modifie le Provisioning Profile pour le re-créer. Pas besoin de le supprimer, on peut cliquer sur “Edit” et le sauvegarder à nouveau.

• Il faut ajouter un nouvel appareil

On ajoute l’appareil dans la liste des Devices puis on modifie les Provisioning Profiles pour cocher l’appareil nouvellement ajouté. Attention, cet appareil ne pourra installer que les prochains builds de l’application (qui seront archivées et signés avec ce nouveau profil).

• On veut distinguer un nouvel environnement

On suit quasiment les mêmes étapes que la création d’un nouveau projet avec le nouvel Identifier que l’on va créer. Il n’y a pas besoin de générer de Certificates ni de saisir des Devices.

• Un nouveau développeur rejoint l’équipe

Il va ajouter son appareil dans les Devices, générer son Certificate (Development) puis modifier le Provisioning Profile (Development) pour y cocher son certificat et son appareil. Il modifiera aussi le Provisioning Profile (Ad-Hoc) pour cocher son appareil.

Remarques : À chaque création ou modification, on pensera à installer la clé privée des certificats et les profils sur les machines qui en auront besoin. Certaines étapes peuvent être automatisées par des outils tels que Fastlane et Codemagic, ou par Xcode.

Les comptes et programmes Apple

Je termine cette épopée en remontant à la surface. Respirons, c’est presque terminé. Il ne nous reste plus qu’à jeter un coup d’oeil sur les types de compte qui existent et ce qu’ils permettent.

• Compte développeur

On s’enregistre en créant/utilisant une Apple ID. C’est gratuit et accessible à tous. On a accès aux outils comme Xcode et les simulateurs. On peut installer l’application sur un appareil relié à notre poste. On ne fait que du développement, aucune distribution possible. On ne peut pas créer de Certificate, de Profile ou autre.

• Apple Developer Program

On souscrit au programme pour 99$ par an, en tant qu’individu ou entreprise. Notre compte développeur aura accès à la distribution Ad-Hoc et App Store. On aura aussi accès à l’App Store Connect. C’est le programme auquel on souscrit dans une immense majorité des cas. On peut tout faire sauf déployer sur un store interne.

• Apple Developer Enterprise Program

On souscrit au programme pour 299$ par an en tant que grande entreprise. Notre compte développeur aura accès à la distribution In-House - c’est seulement pour déployer sur un store interne. L’accès à ce programme est contraint par plusieurs conditions et nécessite une vérification d’Apple. On doit avoir un réel besoin auquel le programme classique ne peut répondre.

Quelques ressources

Petit cadeau de fin, j’ai fouillé les internets d’Apple pour faire remonter des liens utiles. Les voici :

• Developer account
• Developer account - Resources
• Run an app on a device
• Distribution overview
• TestFlight
• App Store Connect
• Creating API Keys for App Store Connect API
• Apple Developer Program
• Apple Developer Enterprise Program

De base, notre backend stocke des données, communique avec d’autres services et applique de nombreuses règles métiers. Notre application, elle, va envoyer une requête pour récupérer des informations, les traiter, appliquer d’autres règles, puis construire un rendu visuel avec divers composants UI (j’ai une bannière, ensuite un carrousel avec trois images, puis une liste d’articles).

On a vu qu’on pouvait ajouter des traitements spécifiques au mobile en ayant un Back for Frontend. Ça nous aide en déportant certaines règles côté backend, en agrégeant des données de plusieurs sources, en facilitant certains changements. Reste encore à construire le rendu visuel côté application.

On en arrive au cran d’après. Bienvenue dans le Server-Driven UI.

Je te dis comment afficher

Avec du Server-Driven UI (aussi appelé Server-Driven Rendering, Backend-Driven UI, …), il y a un backend qui va à la fois retourner des données ET indiquer comment les présenter. Une partie de la construction de l’interface graphique (du front mobile) est déportée côté backend.

Qu’est-ce que ça veut dire, construire l’interface ? Eh bien, le backend indique les composants à afficher (une bannière, un carrousel, une liste d’éléments, une image, …) directement renseignés avec les données associées. De fait, la composition de l’écran est aussi gérée (j’ai d’abord la bannière, ensuite le carrousel, …). Et il pourrait aussi configurer les composants (le texte de la carte est bleu, la police de 16pt, …), les actions lorsque l’on tape sur un élément.

La réponse à une requête sera beaucoup plus riche. Un exemple au format JSON :

{
    "title": "Accueil",
    "content": [
        {
            "type": "carousel",
            "content": [
                {
                    "image": "https://monserveur.com/img/001.jpg",
                    "text": "Arthur",
                    "color": "#FFFFFF"
                },
                {
                    "image": "https://monserveur.com/img/002.jpg",
                    "text": "Perceval",
                    "color": "#FFFFFF"
                },
                {
                    "image": "https://monserveur.com/img/003.jpg",
                    "text": "Lancelot",
                    "color": "#FFFFFF"
                }
            ]
        },
        {
            "identifier": "list",
            "content": [
                {
                    "title": "Les personnages",
                    "description": "En découvrir plus sur les personnages",
                    "details": "88026897-3fcb-4de8-af77-9aeb76d1e8a1"
                },
                {
                    "title": "Les secrets de tournage",
                    "description": "Mystère et magie !",
                    "details": "1da6005c-1f57-4c95-bb1a-6fb3b3a1bde7"
                }
            ]
        }
    ]
}

On obtient donc un nouveau moyen de mettre à jour une application mobile sans passer par les stores. On peut contrôler la construction de l’affichage à distance. Ça nous intéresse car ça nous ouvre des portes pour expérimenter, pour changer plus vite.

Tout cela implique un développement côté serveur et côté application.

• Côté serveur. Il y a une brique / un service / un backend qui construit cette réponse plus complexe. Qui doit avoir cette logique de présentation des données.
• Côté application mobile. Il faut créer chaque composant et il faut une brique qui interprète la réponse du serveur pour la traduire dans les composants correspondants.

Et vu que c’est à notre portée, on peut aller aussi loin que nécessaire pour répondre à notre besoin. On peut avoir une présentation plutôt simple. Le serveur indiquerait seulement des composants à afficher avec leurs données. Ou au contraire, on peut pousser la configuration en détaillant des tailles de texte, des couleurs, des alignements, etc.

On a également le choix d’appliquer ce concept dans les parties de l’application qui nous intéressent. On peut avoir du Server-Driven UI uniquement sur une sous-partie de l’application. Ce n’est pas structurant au point de nécessiter d’en avoir partout. Mais on peut le faire, s’il y a le besoin. On adapte !

Quelques cas - exemples

Pour illustrer et donner de l’inspiration, voici des cas qui existent en production sur des applications grand public.

Une campagne de satisfaction. Sous la forme d’un simple formulaire, avec une suite de questions et plusieurs formats de réponses (choix multiple, choix unique, champs de texte libre). La complexité technique et fonctionnelle est faible. Il ne s’agit que de donner des questions et d’indiquer sous quelle forme on peut y répondre. Il y a un besoin de déclencher une campagne à n’importe quel moment et de moduler le contenu.

Un quizz. On est dans le même ordre d’idées, c’est au final une sorte de formulaire mais présenté sous une autre forme. Ici, le besoin est d’avoir un parcours de questions qui change régulièrement, sans pour autant faire de mise à jour.

Un onboarding. On entre dans un parcours bien plus complexe et lourd. C’est une succession d’écrans avec de nombreuses possibilités comme des formulaires, des listes, des présentation de CGU, de l’upload de fichier, de la visualisation d’images, etc. Les formulaires sont complexes, contiennent des règles de validation, possèdent plusieurs formes (champs libres, choix multiple, champs numéro de téléphone, …). On peut ajouter des boutons et des popups d’aide / assistance. Bref, un parcours complètement modulable car il y a un fort besoin de changement. À l’autre bout, un back-office existe pour configurer tout cela.

Une page d’accueil. Pas de parcours mais une composition de page qui nécessite d’être très modulable. Un jour une simple liste, un autre jour une mise en avant avec une bannière et un el suivi de la liste. Parfois des raccourcis, des cartes d’action rapide. D’autres fois des rappels. Et demain, un peu de tout ça en même temps. D’ailleurs, on expérimente facilement ce qui marche le mieux en changeant à distance l’interface.

Un fil de contenu. Dès lors que le contenu est très dynamique, sa présentation l’est aussi. On a besoin d’adapter les formats.

Bénéfices

Outre la gestion de l’affichage déporté sur un serveur, on peut espérer obtenir d’autres avantages grâce au Server-Driven UI.

Déjà, et c’est ce qui nous intéressait le plus par rapport à notre histoire, à cette série d’articles, on peut changer de nouveaux éléments de notre application mobile sans devoir passer par les stores : l’interface graphique.

Et on est plutôt ravi de cette possibilité. On va pouvoir changer à distance plus profondément l’application, on va pouvoir apporter des changements et des corrections plus rapidement aux utilisateurs. On aura plus de contrôle.

On facilite également l’expérimentation, l’A/B Testing. Pas besoin de Feature Flag, c’est un serveur qui génère la composition de l’écran. C’est déjà de la configuration à distance. On peut donc dès maintenant expérimenter.

Si plusieurs plateformes consomment notre serveur, on gagne une unification des interfaces. Le serveur devient une source de vérité unique, les applications clientes ne feront qu’appliquer la présentation reçue. On a plus facilement une cohérence entre différentes plateformes. Le changement de l’affichage ne se fera qu’à un seul endroit.

Points d’attention

Comme d’habitude, rien n’est magique ou parfait. Le Server-Driven UI ne fait pas exception.

Je commence par enfoncer une porte ouverte. Si on veut que notre serveur retourne un nouveau composant, ou une nouvelle configuration par exemple, il faut le code de notre application puisse l’interpréter. Il faut donc soumettre une mise à jour de l’application pour gérer ces nouveaux cas. Comme si on ajoutait une nouvelle Feature Flag.

Je continue avec une autre porte voisine, les versions. Il faut garder en tête que dans la nature, il y a possiblement une grande variété de versions de notre application. Eh oui, pour rappel, rien n’oblige un utilisateur à mettre à jour une application mobile. Il la fera peut-être rapidement, ou dans une semaine, ou jamais.

On a donc une problématique de rétrocompatibilité. Admettons qu’on ajoute un nouveau composant et qu’on ait une nouvelle version de l’application qui le gère, comment ça se passe pour les anciennes applications ? On peut versionner nos composants. On peut créer un mécanisme de mise à jour forcée. On peut ignorer. On a plusieurs options, mais il faut y penser.

Le Server-Driven UI, c’est également une couche supplémentaire dans notre système. Ça vient avec son lot de complexité, de besoin de maintenance, de debug, etc. Et ça requiert un investissement à l’entrée. Il y a un coût de développement plus élevé au début pour mettre en place les différentes briques et composants pour que tout fonctionne.

Je pense aussi à la sécurité. La surface d’attaque de l’application est augmentée puisqu’elle se base davantage sur des instructions extérieures. Il est facile de modifier à la volée une réponse HTTP. Par exemple, si le serveur indique des intentions de navigation ou d’action, l’application devrait peut-être vérifier que l’utilisateur a bien le droit de le faire.

Pour se lancer

Le sujet du Server-Driven UI étant vaste et complexe, on peut chercher à en apprendre plus en s’inspirant de retours d’expériences de grands noms qui en font ou qui en ont fait de manière poussée : AirBnb, Instagram, Lyft, Reddit, Square.

On peut aussi regarder du côté de frameworks qui existent déjà. En faisant une rapide recherche, je tombe sur DivKit et beagle qui proposent des solutions à la fois côté serveur et côté client iOS, Android, web. J’avais également repéré rfw (Remote Flutter Widget), mais qui me semble d’ailleurs plus proche d’un interpréteur de code. On le verra peut-être dans l’épisode suivant !

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

• #1 Pourquoi
• #2 Remote config, Feature F & 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

J’ai fait le test avec mon téléphone, j’ai eu du mal à trouver une application qui ne faisait aucune requête (en tout cas en apparence, je n’en suis même pas sûr à 100%). J’ai la calculatrice qui vit sa vie dans son coin.

Pourquoi je raconte ça ? Parce que ces applications font très probablement des requêtes vers un serveur qui leur appartient. En d’autres termes, l’équipe, le département, ou l’entreprise qui gère le développement de l’application est également responsable du serveur.

Dans l’épisode précédent, on a vu qu’une configuration à distance permettait de changer le comportement d’une application mobile. Et que la configuration à distance, ce pouvait être simplement un fichier JSON ou une API qui exposait quelques valeurs.

De là à faire le rapprochement entre les données envoyées par nos serveurs et la possibilité de changer le comportement d’une application mobile à distance, il n’y a vraiment qu’un petit pas. Alors faisons-le !

Vers une API spécialisée

En général, ce qu’on retrouve souvent, c’est un backend qui tends vers de l’envoi de données brutes aux fronts. Et qui s’approche plus ou moins du REST. Pour alimenter une page, le front mobile devra effectuer une ou plusieurs requêtes puis traiter les données, appliquer un peu de logique.

Imaginons une page agenda sur notre application. On a envie de mettre en valeur les événements qui ont lieu aujourd’hui, dans de jolis encarts avec un maximum d’informations, ainsi que les 3 prochains événements. Pour le reste, on les groupe par semaine glissante et juste le titre nous suffira.

Notre backend nous propose une route qui retourne 100 événements, à partir du début de la semaine. Côté front mobile, on va devoir trier par date, filtrer les événements passés, mettre de côté les événements du jour et également les 3 prochains pour la mise en valeur, puis ensuite faire des groupes par semaine glissante.

Beaucoup de logique métier qui se retrouve côté client (l’application). Si on décide de changer, disons par exemple la sélection des événements qui sont mis en valeur, il faut modifier l’application et donc redéployer, ce qui implique de traverser tout le process de soumission sur les stores que l’on aimerait éviter.

Sans parler des données qui transitent sur le réseau : on a besoin que du titre pour une grande partie des événements. On augmente au passage la charge serveur pour rien. Bonne nouvelle, on a dit qu’on est responsable du serveur - on peut décider d’y déporter certaines logiques.

Le backend pourrait :

• Trier dans l’ordre adapté,
• Ne renvoyer que les futurs événements.
• Porter la mise en valeur en envoyant deux listes distinctes, et indiquer juste le titre pour les événements lointains.
• Grouper par semaine glissante.
• Aller plus loin en portant la logique de présentation. “Afficher une carte avec un titre, une description, une date pour cet événement mis en valeur, afficher un simple titre pour cet événement, etc”. On commencerait alors à parler de Server-Driven UI.

En fonction de ce que l’on déporte sur le backend, on pourra modifier le comportement de l’application à distance en déployant une nouvelle version du backend plutôt que de l’application. Et c’est souvent bien plus rapide.

Notre API, qui était généraliste, devient spécialisée pour un front.

Le cas GraphQL

Un petit aparté sur GraphQL. Je le mettrais bien dans le panier API généraliste pour notre histoire. Oui, ça apporte une certaine flexibilité au front qui consomme l’API, il peut sélectionner ce qu’il veut, mais à la fin, c’est toujours le front qui construit les requêtes. On veut finalement filtrer les événements passés ? Eh bien il faut redéployer l’application.

Certes, c’est une modification très simple puisque c’est peut-être seulement un paramètre dans la requête GraphQL à ajouter ou modifier, mais cette modification est à faire côté client (notre application). Elle impliquera une soumission de la version sur les stores.

On n’est pas dans la spécialisation de notre API, elle ne porte pas de la logique supplémentaire dédiée au front.

Backend for Frontend

Avoir une API spécialisée, ça peut nous embêter dans certains cas. Si j’ai plusieurs fronts par exemple : un site web et une application mobile. Il y a parfois une logique différente entre les deux. Le web est une autre plateforme, l’interface est très différente. Pour l’agenda, je veux tout afficher sous la forme d’un calendrier mensuel.

On comprend donc l’intérêt d’avoir une API généraliste qui essaye de faire plaisir à tout le monde. Pour autant, on perçoit aussi les avantages d’avoir une API spécialisée. C’est là qu’intervient le principe de Backend for Frontend : on peut avoir les deux !

Un Backend For Frontend, souvent connu avec l’acronyme BFF, est une couche intermédiaire entre un backend et un frontend. Concrètement, c’est un backend supplémentaire qui va traiter des données spécifiquement pour un type de front (une application mobile par exemple).

Notre front mobile va effectuer toutes ses requêtes en passant par le Back for Front, et uniquement ce dernier. C’est le Back for Front qui appellera le backend pour obtenir les données nécessaires. Il pourra ensuite appliquer de la logique dédiée avant de renvoyer les données à l’application mobile. Le site web aurait de son côté son propre Back for Front.

Vu que le Back for Front devient le point d’entrée unique du front, il peut servir d’agrégateur. Peut-être que pour notre agenda, on avait besoin de la liste des événements futurs et également des événements où l’on est inscrit. Plutôt que de faire deux requêtes, le front n’en fera qu’une seule vers le BFF.

Avec cette mécanique, on voit rapidement plusieurs avantages :

• On sépare les logiques spécialisées. Il y a un BFF mobile, un BFF web, etc.
• On sépare la partie spécialisée de la partie généraliste. Il y a un backend qui ne subit pas les caprices du front.
• Un développeur mobile peut plus aisément sortir de son éco-système et effectuer des changements sur le BFF.
• On peut regrouper plusieurs ressources en une seule route, et réfléchir en termes de page, d’écran.
• On cache la complexité au front. Il n’y a pas à savoir s’il y a plusieurs services ou même s’il y a un partenaire externe.

Et notamment, ce qui nous intéresse particulièrement dans cette série d’articles, on déporte de la logique client (app mobile) sur un serveur distant (notre BFF). On peut donc modifier du comportement sans passer par les stores ! On aime :)

C’est tout de même une décision à peser dans l’équipe. Qui dit couche supplémentaire, dit une maintenance supplémentaire. Il y a une nouvelle brique qui doit évoluer et être déployée. Déléguer davantage au Back for Front augmente au passage les possibilités d’erreurs sur l’application - elle est plus permissive. On songera à monitorer plus en profondeur ce qu’il se passe dans l’application.

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

Eh bien, c’est ce qui se cache derrière des concepts comme le Remote Config et le Feature Flagging. Ce sont des techniques de développement qui permettent de modifier des éléments d’une application sans avoir à déployer une nouvelle version. Les répercussions arrivent très peu de temps après (quelques minutes) et ne nécessitent aucune intervention de l’utilisateur. On peut changer le comportement d’une fonctionnalité, un algorithme, et même l’interface graphique.

On peut utiliser ces techniques sur un site web, une application mobile, un backend. Partout ! Le principe de base est très simple. D’un côté, il y a une configuration distante (sur un serveur par exemple). C’est un ensemble de paramètres avec des valeurs que l’application pourra interpréter - Activer le partage ? NON - et ça peut être un simple fichier JSON :

{
	"feature_share_enabled": false 
}

D’un autre côté, il y a une application qui récupère cette configuration régulièrement depuis le serveur et qui contient du code utilisant les différents paramètres reçus pour adapter son comportement. Par exemple, le nombre d’éléments de ma page d’accueil n’est pas un chiffre fixe dans mon code, mais correspond à celui indiqué dans ma configuration à distance.

let numberOfElements = remoteConfig.get("home_number_of_elements") 

La récupération peut se faire par pull - c’est l’application qui demande régulièrement la configuration - ou par push - c’est le serveur qui indique à l’application qu’il y a un changement. Ou même un mélange des deux, le push permettant d’avoir une bonne réactivité s’il y a un changement critique.

J’insiste sur un point important. Du code doit être au préalable ajouté dans l’application en production pour réagir à chaque nouveau paramètre que l’on veut ajouter à la configuration. En d’autres termes, si je veux désactiver le partage, je dois écrire du code qui conditionne l’affichage ou non de mes boutons de partage. Et je dois aussi déployer cette version en production. Ce n’est pas magique, il faut prévoir ce travail.

Une fois que j’ai rendu configurable mes fonctionnalités, je n’ai qu’à modifier des valeurs dans ma configuration distante pour affecter mon application sans avoir ni à modifier son code ni à la déployer ! On décorrèle le déploiement du code de celui de la feature, ce qui nous ouvre de multiples possibilités.

Cas d’utilisations

Sans chercher à faire une liste précise et exhaustive, je vais parcourir plusieurs exemples afin de donner de la variété dans les cas d’utilisations - c’est bien plus qu’un bouton on/off.

• Désactiver une fonctionnalité. J’ai soudainement un problème en production. La dernière fonctionnalité provoque un crash, une forte charge sur le serveur, se comporte anormalement. Ou un SDK tierce - qui se souvient du SDK de Facebook il y a quelques années ? Il a provoqué le crash au lancement d’innombrables apps, y compris les géants comme Spotify ou TikTok. Je peux réagir très vite en désactivant la fonctionnalité puis en analysant le pourquoi ensuite (Cynefin : on est dans le chaos, on cherche à agir tout de suite). On se met un filet de sécurité, un kill switch, on peut rollback. Ou peut-être qu’il n’y a aucun problème et que la fonctionnalité est simplement éphémère - on l’arrête sans nécessité de mise à jour.

• Activer une fonctionnalité. J’ai le besoin inverse, activer plus tard une fonctionnalité. Peut-être qu’il faut attendre que la version de l’application soit assez déployée pour activer la fonctionnalité. Ou une date, un événement. Peut-être parce que le backend n’a pas encore terminé tout le travail requis. Ou parce qu’on veut intégrer et déployer continuellement (CI/CD) - on cache la fonctionnalité tant que le travail est inachevé.

• Modifier l’expérience utilisateur. De manière plus générale, on peut modifier l’expérience utilisateur sous différents aspects. Ce n’est pas uniquement binaire “activé ou désactivé”. Je peux modifier l’agencement d’une page, un nombre d’éléments. Je peux créer une mécanique pour forcer la mise à jour de l’application (on indique un numéro de version minimal, et l’application aurait un écran incitant à mettre à jour au lancement).

• Déployer progressivement une fonctionnalité. Apple et Google proposent tous les deux du déploiement progressif sur leurs stores. Ici, on pourrait très bien le faire au niveau d’une fonctionnalité. Je pourrais déployer ce nouveau tunnel à 10% des utilisateurs, et j’observe ce qu’il se passe. J’augmente le pourcentage quand et comme je le souhaite (ce que ne permet pas la solution sur l’App Store). On fait du Canary Release. Et je peux même réduire à 0% si j’ai un gros problème. Plus personne n’y aura accès. Un avantage par rapport aux déploiements progressifs via les stores : stopper le déploiement ne fait qu’empêcher de nouvelles installations, ceux qui ont déjà installé garderont la fonctionnalité active.

• Expérimenter des variantes. J’ai envie de tester en production un affichage différent, un autre parcours, un placement, une couleur. Peut-être même deux solutions pour améliorer un problème. On va faire vivre ces deux variantes dans la nature en même temps et observer laquelle obtient le meilleur résultat. On fait de l’A/B Testing.

• Bêta-tester. Je peux créer un groupe de bêta-testeurs ou d’early adopters pour donner accès en avance à des fonctionnalités. Ou je pourrais même avoir un opt-in dans l’application. Et j’active ou désactive plus largement dans le futur.

J’en profite pour rebondir sur cette dernière phrase. On peut combiner des cas d’utilisations. Parce que j’ai rendu configurable cette fonctionnalité, je peux commencer à l’ouvrir à mon groupe de bêta-tester, puis ouvrir à 10% de tous mes utilisateurs, puis désactiver la fonctionnalité quand un problème se présente. Et toujours sans avoir à déployer une nouvelle version.

Je veux ça !

Okkkayyyy je commence à être convaincu par l’idée, j’ai envie de l’intégrer sur mon projet, dans mon équipe. Quelle solution prendre ?

Première étape, j’opterais pour une autre question : quels sont mes besoins ? Plutôt que de foncer sur un outil parce qu’il a l’air cool ou parce qu’untel a dit qu’on a raté notre vie si on ne l’utilise pas, je préfère regarder mon contexte et mes besoins pour répondre de manière adaptée.

Ici, on peut se demander si on veut une configuration qui expose simplement des valeurs, ou si on veut pouvoir introduire des variantes pour faire de l’A/B Testing, du déploiement progressif, etc. Qui va modifier la configuration ? Un fichier versionné sous git pourrait suffire, mais une interface web serait plus adaptée si on veut que toute l’équipe puisse apporter des changements. Quel contrôle veut-on sur les données ? Une solution hébergée chez nous ou un SaaS clé en main ? Et le feature flagging au final, est-ce ce qui répond le mieux à notre besoin ?

À partir de ces réflexions, je peux aller dans plusieurs directions.

• Je peux créer moi-même une solution. La mécanique de base est simple. Notre backend qui expose un fichier JSON ou une route avec la configuration et un appel HTTP classique côté app pourrait suffire. Un peu de gestion de cache. On a un contrôle total, c’est hébergé chez nous. Puis peut-être qu’on ajoute une interface web, de la variance, etc. Ce sont des ajouts qui prendront un peu plus de temps et qui pourraient diriger vers une solution open-source ou SaaS pour éviter de réinventer la roue.
• Je peux héberger une solution open-source chez moi. J’ai rapidement accès à de multiples fonctionnalités et en même temps, je garde un assez bon contrôle. Je gère juste que ça tourne bien sur mes serveurs. Unleash et Featurehub sont deux possibilités.
• Je peux utiliser une solution propriétaire dans le cloud. Je ne veux rien gérer, je délègue tout. Je peux très rapidement mettre en place une configuration à distance pour mon projet, mais j’ai moins de contrôle. Firebase Remote Config a démocratisé la technique pour les applications mobiles, et est très souvent utilisé. C’est Google derrière et aux USA, à avoir en tête pour les données :). Optimizely et ConfigCat sont deux alternatives intéressantes ; la dernière proposant une option pour un cloud privée.

Conclusion

J’aime bien les techniques de Feature Flag et Remote Config parce qu’elles sont simples et qu’elles apportent une réelle flexibilité en séparant le déploiement du code et de la fonctionnalité. On peut réagir à certains imprévus, on peut expérimenter en production, on peut modifier l’expérience utilisateur.

Vous avez pu voir que plusieurs autres pratiques et concepts gravitent autour des Feature Flags. L’A/B Testing, le kill switch, le Canary Release, par exemple. C’est aussi une brique que l’on peut retrouver quand on se plonge dans l’intégration continue (CI), le déploiement continu (CD), le trunk-based development - la configuration permettant d’intégrer et de livrer très régulièrement en cachant le travail non terminé.

Pour autant, les Feature Flags ne sont ni magiques ni parfaites. Il faut prendre soin d’en mettre aux endroits adaptés. Il faut une hygiène dans l’équipe pour les maintenir, les supprimer, éviter les chevauchements.

Elles permettent d’expérimenter en production, mais elles ne remplacent pas des entretiens et ateliers avec des utilisateurs, de la discovery, etc. C’est complémentaire.

Elles permettent d’ajouter un filet de sécurité. Elles ne remplacent pas une attention à la qualité de code, au design applicatif, aux tests, etc. Ajouter -> il est supplémentaire.

Et au fait, on dit Feature Flag, Feature Toggle, ou Feature Flip ? C’est la même chose. J’ai une préférence pour Feature Flag qui est moins binaire.

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

On a cependant deux barrières de taille au changement rapide dans le développement mobile : les stores (App Store et Google Play), et les utilisateurs.

Pour un site web ou un backend, on peut avoir la totale maîtrise du déploiement. Si on veut mettre en ligne la toute dernière version, on peut le faire en quelques secondes - c’est notre serveur, on décide de ce qu’il exécute. Les utilisateurs y auront accès tout de suite et n’auront d’ailleurs pas le choix - derrière l’url de notre site web, il y a toujours notre dernière version.

Pour une application mobile, je disais qu’on a deux barrières. D’abord, les stores.

C’est notre première halte sur la route du déploiement. Ici, on ne maîtrise pas. On est chez Apple et chez Google. Il y a une étape de vérification de l’application que l’on soumet. Le temps d’analyse est variable et dépend d’eux, et ils peuvent refuser comme bon leur semble. Côté Apple, c’est d’ailleurs un sport national - les règles sont plus strictes et l’application peut soudainement être refusée pour un élément qui est en prod depuis plusieurs versions.

Une fois que l’application est acceptée et déployée sur les stores, on ne peut pas encore crier victoire - c’est au tour des utilisateurs d’installer l’application.

Seconde halte pour le déploiement donc, et on ne maîtrise toujours pas. Les utilisateurs vont mettre à jour quand ça leur chante : le jour même, le lendemain, 2 semaines après, 6 mois, jamais. Les utilisateurs ne sont d’ailleurs pas spécialement notifiés qu’une nouvelle version est disponible. Ils doivent aller sur les stores eux-mêmes.

Et ceux qui activent les mises à jour automatique ? Elles ne sont pas instantanées pour autant. Le système décide de lancer le téléchargement lorsque certaines conditions sont réunies (connexion à un réseau Wi-Fi, batterie en charge, heure de la journée, utilisation du téléphone).

Ce qui veut dire que si ma nouvelle fonctionnalité provoque un crash en production, il faut passer par toutes ces étapes pour corriger le problème. Un processus long, et sans garanti. Les utilisateurs auront peut-être désinstallé l’application avant que ce ne soit réglé et livré.

Face à ce risque, certaines équipes vont entrer dans ce que je trouve être un cercle vicieux : on a peur de faire des erreurs parce que le changement sera long, donc on s’ajoute du contrôle et des process, ce qui allonge le temps avant de livrer, donc on a encore plus peur, on contrôle davantage, on allonge d’autant le délai, etc. Au final, cette équipe va se figer, les livraisons deviendront douloureuses et les problèmes se multiplieront.

D’autres équipes vont plutôt se diriger vers des pratiques vertueuses. Elles vont par exemple chercher à intégrer et déployer en continu (CI/CD) chaque changement. J’entends bien plus souvent ces sujets dans le monde du web, et surtout du backend. Cependant, sur mobile, il existe aussi des techniques pour s’approcher des principes de CI et CD malgré les deux barrières que sont les stores et les utilisateurs.

On peut effectuer des changements sur une application mobile en prod sans pour autant devoir déployer une nouvelle version sur les stores. Et ça tombe bien, j’avais envie de faire un petit tour d’horizon pour faire découvrir quelques possibilités avec cette 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