Jusqu’à créer un environnement de QA pour simulateurs iOS/Android dans le navigateur — pourquoi nous avons abandonné MSE

Toute équipe qui développe des applications mobiles l’a probablement déjà vécu au moins une fois. Il manque toujours des appareils de test, et il est difficile de couvrir correctement toutes les versions d’OS. Mais utiliser des simulateurs impose Xcode ou Android Studio, ce qui bloque d’emblée les membres de l’équipe qui n’ont pas d’environnement de développement mobile, comme les chefs de produit, les designers ou les développeurs backend. À chaque demande du type « Je veux juste voir ce qui a été déployé sur le sandbox, comment j’installe l’app ? », un développeur mobile doit s’arrêter de travailler pour aider.

Nous avons aussi étudié Appetize et BrowserStack. Mais entre (1) des coûts qui grimpent vite à mesure que l’équipe grandit et (2) le fait que les binaires de l’app soient envoyés vers un cloud externe, nous avons finalement décidé de le construire nous-mêmes avec un Mac inutilisé.

C’est ainsi qu’est né tapflow — un outil open source auto-hébergé qui permet à n’importe qui dans l’équipe de faire du QA mobile avec des simulateurs iOS et des émulateurs Android directement dans le navigateur. Côté utilisateur, rien à installer : il suffit d’ouvrir un navigateur. Et comme c’est auto-hébergé, les données de l’application ne quittent pas le Mac de l’équipe.

La plus grande difficulté pendant le développement n’a pas été la fonctionnalité, mais la latence. Dès que l’affichage prend juste une demi-seconde de retard, tout le monde essaie un scroll puis ferme la page. En plus, l’écran du simulateur passe par une pipeline agent → relay → rendu navigateur, ce qui accumule de la latence à chaque étape. Voici ce que nous avons mis en place pour réduire cette latence sur ce parcours :

• Nous avons abandonné MSE. Le buffer média de <video> imposait structurellement ~235 ms, donc nous l’avons remplacé par une architecture à 2 niveaux WebCodecs (contexte sécurisé) / WASM tinyh264 (HTTP non chiffré). En déclarant reorder=0 dans le SPS, nous sommes passés de 267 ms à 2,5 ms entre decode et present. (mesure à horloge unique sur localhost)
• Nous avons benchmarké 4 décodeurs (tinyh264/FFmpeg/openh264), mais avons finalement conservé tinyh264 — FFmpeg n’était meilleur que sur les écrans statiques, et perdait systématiquement sur le scroll, tout en ayant un bundle 11 fois plus lourd. Le vrai goulot n’était pas le décodeur, mais la charge et le transport.
• Nous avons amélioré l’encodage logiciel Android grâce à l’encodage matériel du Mac. L’émulateur n’a pas d’encodeur H.264 matériel, donc scrcpy se retrouve limité par l’encodeur logiciel (22–29 fps). Nous extrayons les frames brutes vers l’hôte via gRPC puis les encodons avec VideoToolbox sur Mac → 59 fps (avec downscale). (capture par défaut à 30 fps, les appareils physiques conservent scrcpy)
• Injection tactile iOS sans WDA (injection directe via l’API HID de CoreSimulator), et l’agent Mac se connecte uniquement en sortie au relay (pas besoin de règle de pare-feu en entrée).

Limites : l’agent iOS est réservé à macOS, le tactile repose sur une API privée qui peut casser lors d’une mise à jour de macOS, le projet est encore en v0.x, et les appareils physiques ne sont pas encore pris en charge.

npm install -g tapflow  
tapflow start   # → http://localhost:4000  

Licence MIT
GitHub: https://github.com/jo-duchan/tapflow
Documentation : https://www.tapflow.dev

Si vous avez déjà rencontré des problèmes d’accès aux simulateurs, ou si vous avez un avis sur le streaming à faible latence ou l’usage d’API privées, vos retours sont les bienvenus.