Expo et React Native : des bugs natifs, plateforme par plateforme

Les projets

En une phrase : React Native permet de créer des applications iPhone et Android avec le même code, et Expo est la boîte à outils qui rend la création, les tests et la publication de ces apps beaucoup plus simples.

Traditionnellement, une entreprise qui veut une app sur iPhone et sur Android paie deux applications : une écrite en Swift pour Apple, une en Kotlin pour Google. React Native, créé chez Meta, a changé cela : on écrit l'app une seule fois en JavaScript et React, et elle affiche de vrais écrans natifs sur les deux plateformes — pas un site web déguisé en application. Des apps que vous utilisez peut-être tous les jours sont construites ainsi.

Expo s'appuie dessus. Il fournit des briques prêtes à l'emploi pour ce que font les téléphones — appareil photo, micro, notifications, images, localisation — et peut compiler et publier les apps dans le cloud : pas besoin d'un Mac pour sortir une app iPhone.

Ce qui le rend innovant

• Une app, deux plateformes. Une seule équipe développe pour iPhone et Android en même temps, et les utilisateurs ont quand même une vraie app native.
• Les fonctions du téléphone simplifiées. Appareil photo, micro ou notifications tiennent en quelques lignes de code au lieu de semaines de travail spécifique à chaque plateforme.
• Pas besoin d'un ordinateur particulier. Les apps peuvent être compilées et envoyées sur l'App Store et Google Play depuis le cloud.
• Des bugs vérifiés par un robot. Expo utilise un assistant automatique qui essaie de reproduire chaque bug signalé et vérifie les corrections proposées — je l'ai vu à l'œuvre sur mes propres contributions.

En bref : ma contribution et ce que j'en retiens

Ma part : j'ai proposé 18 corrections ; 4 font déjà partie d'Expo et les autres sont en cours de relecture (aucune de mes corrections React Native n'est encore acceptée). Celles qui sont acceptées ont réglé de vrais problèmes pour les créateurs d'apps : un enregistrement audio qui pouvait rester bloqué indéfiniment, une caméra sur le web qui se disait « prête » avant de l'être, une compilation qui plantait sur les ordinateurs Windows, et un plantage de l'app sur les téléphones dont la carte SIM n'avait pas de nom d'opérateur.

Ce que j'en retiens : sur mobile, les bugs les plus difficiles viennent du timing et des différences entre appareils et navigateurs — ce qui marche sur l'un peut échouer sur l'autre. Et être clair sur ce qu'on a pu ou non tester gagne la confiance des relecteurs.

---

La suite de l'article entre dans les détails techniques, pour les développeurs.

Sous le capot

React Native (126k étoiles, MIT) — moteur de rendu Fabric, JSI, TurboModules ; Expo (52k étoiles, MIT) — Expo Modules API en Swift/Kotlin, CLI, Expo Router, config plugins et EAS.

En détail : ce que j'ai apporté

Ma contribution en chiffres : 18 pull requests — 4 mergées dans Expo, 9 autres ouvertes là-bas, et 4 ouvertes dans React Native. Pour être clair : aucune de mes PR React Native n'est encore mergée.

Mergé dans Expo

• expo-audio (Android, Kotlin). Avec l'enregistrement en arrière-plan activé, prepareToRecordAsync() pouvait attendre indéfiniment : un timeout de connexion existait mais n'était jamais lancé. Le lancer a révélé un deuxième problème — le timeout tourne sur un thread, le callback du service sur un autre, et une continuation de coroutine ne peut être reprise qu'une fois. Le mainteneur a pointé une course « vérifier puis agir » restante ; la version finale prend et vide la continuation de façon atomique, puis rejette et se déconnecte.
• expo-camera (web). onCameraReady se déclenchait avant que la <video> ait une image, donc takePicture échouait avec « caméra pas prête ». Il attend maintenant que le flux soit attaché et que de vraies données arrivent. Une première version attendait HAVE_ENOUGH_DATA, que WebKit n'atteint jamais dans ce cas ; après le passage du bot, je suis passé à « une image courante et une largeur ». Résultat : 25/25 réussites sur Chromium, Firefox et WebKit, contre 25/25 échecs avant.
• expo-widgets (Windows). Le résolveur Metro remplaçait tout nom qui n'était pas un fichier par un module vide — y compris le chemin absolu Windows du module vide lui-même, ce qui bouclait jusqu'au dépassement de pile. Reconnaître les chemins D:\… comme des fichiers l'a corrigé, confirmé par le bot sur une VM Windows.
• expo-cellular (Android). simOperator?.substring(0, 3) plantait quand l'opérateur était une chaîne vide : ?. protège de null, pas de "".

En revue

• expo-image : un JPEG de 7200×7200 qui plantait avec « trying to draw too large bitmap », et des décodeurs SVG qui acceptaient tous les fichiers — chargeant des vidéos entières en mémoire.
• Cœur Android : une intention de lancement perdue au redémarrage de l'app, ce qui faisait renvoyer null à getLastNotificationResponseAsync().
• task-manager iOS : des courses entre le thread de lancement et une tâche qui se termine, dont un possible use-after-free.
• React Native : une correction iOS d'un seul mot — unsignedIntValue tronquait UIDataDetectorTypeAll (une valeur 64 bits « tous les bits ») à 32 bits, donc dataDetectorTypes="all" ne faisait rien avec la New Architecture ; Symbol.toStringTag sur Blob, File et URL pour que des librairies comme axios les reconnaissent ; et les types TypeScript du global performance.

Les leçons techniques

• Les bugs natifs sont souvent des bugs de concurrence ou de taille. Deux threads qui reprennent une même continuation, un drapeau 64 bits stocké sur 32, une image plus grande que ce que le GPU accepte. La surface JavaScript montre rarement où est le vrai problème.
• Tester sur tous les moteurs, pas seulement le navigateur qu'on préfère. Ma première correction de la caméra marchait sur Chromium et échouait une fois sur deux sur WebKit. Mesurer la disponibilité comme chaque moteur la rapporte était la vraie correction.
• Le chaînage optionnel n'est pas une validation. ?. protège de null ; les chaînes vides, les valeurs partielles et les mauvaises longueurs demandent des vérifications explicites.
• Être honnête sur ce qu'on a pu exécuter. Je n'ai pas pu lancer certaines corrections Android sur un appareil, et je l'ai dit dans chaque PR. La vérification automatique et la CI ont comblé une partie du manque ; le reste, c'est aux relecteurs de trancher.
• Les grands projets demandent de la patience. Quatre PR mergées dans un framework aussi utilisé m'ont plus appris sur la culture de la revue que n'importe quel tutoriel : des diffs courts, un changeset, et un « avant / après » clair.