Shipping Feyz : une application de réflexion religieuse pour React Native, passant d’un projet secondaire aux stores
Comment une base de code TypeScript React Native a permis à Tawakkul de passer à Feyz, grâce à une gouvernance des stores, à des performances améliorées sur les appareils anciens et à une expérience d’utilisation permettant une réflexion sans distractions.
De nombreux ingénieurs se fixent en secret l’objectif de transformer une idée originale issue d’un dépôt vierge en un produit disponible dans les stores publics. Ce but peut sembler lointain pendant longtemps. Grâce à un produit mobile multiplateforme nommé Feyz — qui a d’abord porté le titre provisoire de Tawakkul — cet objectif a été atteint sous forme d’application distribuée sur l’App Store et le Play Store. Parmi les projets React Native, celui-ci se distingue par son importance particulière, car il a nécessité des décisions concrètes liées à la production plutôt que de se contenter de solutions pédagogiques simples.
Origines du produit et orientation plus claire de l’interface
Feyz n’est pas apparu du néant. Les progrès se sont accélérés grâce à la collaboration avec un développeur collègue qui a introduit des frameworks natifs multiplateforme et offert un accompagnement continu tout au long de la phase d’apprentissage initiale.
La vision du produit était d’offrir un espace épuré et peu perturbant, permettant aux utilisateurs d’intégrer une conscience spirituelle ainsi que des réflexions sur la foi au sein de leurs agendas chargés. L’examen des applications existantes dans cette même catégorie a révélé un manque criant : de nombreuses applications soit masquaient l’expérience derrière des interfaces encombrées et dépassées, soit attiraient inutilement l’attention avec des performances lentes et une optimisation insuffisante. Ce qui a commencé comme un simple croquis pour une petite utilité s’est transformé en un projet ciblé à plus haute qualité.
Le choix de React Native pour les deux plateformes
La planification du déploiement a soulevé le dilemme habituel : développer des bases de code natives distinctes en Swift et Kotlin, ou adopter une approche cross-platform commune. React Native s’est avéré supérieur sur le plan logistique. Une seule base de code en TypeScript, capable de générer des binaires d’interface natifs pour Android et iOS, a permis de réduire le temps de développement et d’éliminer les redondances dans la logique du produit.
Le projet est également devenu une salle de classe pratique pour React Native. Le travail a dépassé les cours vidéo structurés et les dépôts d’exemples génériques. Au lieu de styliser des écrans statiques, les efforts se sont concentrés sur l’hydratation asynchrone de l’état, des points de terminaison dynamiques, ainsi que sur des composants de mise en page qui devaient fonctionner correctement quelles que soient les densités de pixels.
Architecture de développement et gouvernance post-lancement
Passer d’une application multiplateforme depuis un émulateur local à une étape de review dans la boutique officielle introduit un type différent d’obstacles. Un code de composants propre s’est avéré être la tâche la plus facile à mettre en œuvre. La maturité du projet est arrivée avec la résolution des goulots d’étranglement liés au déploiement.
Tout d’abord, l’expérience utilisateur devait rester intuitive : suppression des éléments superflus du menu, layout minimaliste, et possibilité d’accéder aux réflexions spirituelles via une seule cible de toucher peu gênante. Ensuite, la télémétrie et le flux de données nécessitaient une mise au point minutieuse afin que l’état du système reste stable de manière prévisible, sans bloquer le thread principal sur des matériels plus anciens. Enfin, la configuration de la plateforme native exigeait que les permissions Android, les arbres de dépendances CocoaPods et les paramètres des paquets locaux soient ajustés pour éviter les plantages en temps de fonctionnement lors de la gestion du magasin.
Changer le nom de Tawakkul en Feyz allait au-delà d’une simple question esthétique. À mesure que la télémétrie de production s’accumulait et que les profils des utilisateurs se stabilisaient, Feyz correspondait mieux à un produit mature, inclusif et plus large. Ce changement de nom reflétait les améliorations en termes de qualité et d’étendue du code, tout autant que les aspects liés à la marque.
Ce que le déploiement a appris sur l’art de l’ingénierie
La création et la publication de l’application ont remis en question l’idée selon laquelle une ingénierie d’élite équivaut à la syntaxe la plus astucieuse. Pour livrer un produit réel, il faut mettre de côté son ego et penser comme un créateur de produits. La patience face à des configurations d’environnement défaillantes, la cohérence au cours des cycles de rejet par les stores, ainsi que l’humilité lors de l’analyse des retours réels des utilisateurs sont plus importants que les algorithmes spectaculaires. Finaliser une application et la maintenir en bon état en production exige une discipline que la création d’un nouveau répertoire ne permet jamais d’acquérir. Feyz n’est plus simplement un dossier GitHub ; c’est la preuve qu’une idée bien ciblée peut atteindre la ligne d’arrivée en production.
Essayer les versions en direct
Les ingénieurs, les concepteurs et les lecteurs intéressés par les produits qui souhaitent auditer l’interface de production, tester le rendu multiplateforme ou explorer l’architecture de réflexion peuvent installer les binaires en temps réel depuis les listages publics d’Apple App Store et de Google Play pour Feyz.
Le parcours allant d’un concept abstrait à une mise en ligne dans un magasin reste identique pour tout projet similaire : choisir une stack qui assure la compatibilité entre les plateformes, concevoir en privilégiant la concentration plutôt que le bruit des fonctionnalités, et considérer les règles du magasin ainsi que la telemétrie post-lancement comme des tâches d’ingénierie de premier plan et non comme des considérations secondaires. React Native a rendu les publications sur deux plateformes gérables ; les contraintes de production ont donné à ce travail sa véritable dimension. Une hydratation qui ne bloque jamais les appareils anciens, des permissions qui résistent aux vérifications, et des arbres CocoaPods cohérents ne sont pas spectaculaires, mais ils déterminent si les utilisateurs pourront jamais profiter de l’expérience de réflexion.
Pour les équipes qui envisagent React Native pour une application ciblée aux exigences similaires, la leçon est pratique. Le TypeScript partagé permet de transporter à la fois l’interface utilisateur et la logique métier entre les différentes plateformes, mais des différences natives persistent : demandes de permissions sur Android, graphes de dépendances sur iOS, ainsi que des variations matérielles. Allouez du temps dès le début pour gérer ces différences. Considérez les versions fonctionnelles sur émulateur comme un point intermédiaire, et non comme une fin. Les pipelines de déploiement, les notes de rejet et les tests de performance sur des appareils anciens sont ce qui transforme un projet pilote en un fichier exécutable maintenu.
Les applications développées de manière indépendante enseignent également l’implication totale sur tout le cycle : l’idée initiale, l’expérience utilisateur, les modules TypeScript, la configuration native, la soumission et le suivi de la santé en temps réel. C’est ce cycle qui transforme un objectif abstrait en quelque chose que les utilisateurs peuvent télécharger dès aujourd’hui.