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.

De nos jours, il est rare de trouver une application qui ne communique pas du tout avec l’extérieur. La majorité des applications que l’on utilise font des requêtes vers un ou plusieurs serveurs - pour demander des données, les afficher dynamiquement, et pour en envoyer. 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%).

Je suis dans une équipe qui travaille souvent à distance, et pourtant, j’ai la sensation d’avoir mes collègues à côté de moi. Cette petite tape sur l’épaule venant d’une personne qui passe dans les bureaux pour demander de l’aide ou discuter, vous voyez ? Eh bien, je l’ai même quand je suis seul à mon domicile, et je ne suis pas fou - enfin, pas complètement ;). Pour poser un peu de contexte, nous sommes une vingtaine dans l’équipe, composés de multiples profils (tech, produit, terrain, design, …).

Et s’il suffisait de passer à non un paramètre pour désactiver une fonctionnalité qui pose problème en prod ? Ou de changer un chiffre pour modifier le nombre d’éléments de la page d’accueil d’une application mobile ? Sans avoir à modifier du code et sans passer par la case déploiement bien entendu, parce qu’on a envie d’agir rapidement. On pourrait simplement changer des valeurs sur une interface web par exemple.

Simple, compliqué, complexe, chaos. Et si on déterminait dans lequel de ces lieux se situe une user story, une epic, une idée ? Ça ouvrirait des discussions et des questions très intéressantes pour que l’équipe s’adapte - elle n’a pas besoin de traiter les stories tout le temps de la même manière. Je pense par exemple au flux que la story doit traverser, aux process, aux pratiques tech et produit, à la façon de communiquer et de collaborer, etc.