L’Intelligence Artificielle. C’est sur toutes les lèvres en ce moment. En particulier chez les développeurs puisqu’on est triplement concernés : c’est un nouvel outil pour nous assister, c’est un nouveau produit avec lequel on peut créer des fonctionnalités, et c’est peut-être aussi quelque chose qui pourrait nous remplacer. Ça y est, dès le premier paragraphe, le mot est lâché. Les IA vont nous remplacer. C’est en tout cas ce qui est annoncé pour l’année prochaine de manière tonitruante sur LinkedIn et Twitter, c’est donc forcément vrai !

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).