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.

Diversifier, c’est mettre de la variété en quelque chose, l'enrichir avec des éléments différents. Un concept simple à comprendre mais que l’on n’applique peut-être pas assez. Il y a des moments et des domaines où la diversité est un aspect important, voire essentielle. Je prends en exemple la nutrition pour illustrer. On sait qu’il faut avoir une bonne variété d’aliments pour obtenir les différents nutriments, vitamines et minéraux. C’est essentiel pour notre santé.

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.

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.

Le mois dernier, je m’essayais sur un format de recap. Un rapide tour d’horizon des actualités dans le monde des applications mobiles. On regarde brièvement ce qu’il s’est passé le mois précédant du côté de iOS, Android, Flutter, ou plus haut niveau chez Apple et Google. Un mélange d’informations tech, de produits, d’événements. Voici le récap de Février :) Ça s’est passé récemment Plus de 1000 applications conçues pour le Vision Pro Mi-février, une pointure d’Apple a annoncé sur Twitter que plus de 1000 applications ont été créées spécialement pour le Vision Pro.

Certificate, Provisioning Profile, Ad-Hoc, Distribution, Code signing, … Bienvenue dans le monde complexe de la distribution d’applications iOS. C’est un sujet qui peut dérouter, et malheureusement, on s’y confronte dès lors que l’on veut distribuer une application. 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.

J’ai envie d’essayer un nouveau format mensuel. Un rapide tour d’horizon des actualités dans le monde des applications mobiles. On regarde brièvement ce qu’il s’est passé le mois précédant du côté de iOS, Android, Flutter, ou plus haut niveau chez Apple et Google. Un mélange d’informations tech, de produits, d’événements. Ça s’est passé récemment Apple Vision Pro Le dernier pari technologique d’Apple, le casque de réalité mixte, sort aujourd’hui en boutique aux USA.

En ce moment, je dois intégrer des SDKs natifs Android et iOS dans une application développée avec Flutter. L’un des SDK est distribué via un cocoapods privé, l’autre sous la forme d’une librairie java. C’est un exercice intéressant. J’ai envie de partager le cheminement que l’on a fait avec mes pairs, et expliquer pourquoi on a terminé par faire un simple passe-plat. Une recette native J’enfonce peut-être une porte ouverte, mais ça me semble important à expliciter.

Et si on poussait le concept de Backend for Frontend encore plus loin, à l’extrême ? Un peu à l’image de l’Extreme Programming qui pousse des pratiques dans leurs retranchements. Qu’est-ce que ça pourrait donner pour notre histoire de backend et de front mobile ? Pourrait-on déporter jusqu’à l’UI de l’application ? 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).

Le terminal, c’est une sorte de couteau suisse pour les développeurs. Il permet de faire énormément de choses - presque tout d’ailleurs - et on s’en sert très souvent. Alors quand le temps de lancement du terminal s’allonge, je ne vous cache pas que c’est très embêtant. C’était mon cas avec iTerm2 + oh-my-zsh, et on va voir comment trouver les problèmes à la source. Identifier les causes Je n’ai pas forcément fait attention au moment exact où mon terminal a commencé à être capricieux pour se lancer.