Hasta crear un entorno de QA con simuladores de iOS/Android en el navegador — por qué descarté MSE

Si trabajas en un equipo que crea apps móviles, seguramente te ha pasado al menos una vez. Siempre faltan dispositivos de prueba, y también es difícil cubrir de forma equilibrada distintas versiones del sistema operativo. Pero si intentas usar simuladores, necesitas Xcode o Android Studio, así que para miembros del equipo sin entorno de desarrollo móvil, como planners, diseñadores o desarrolladores de backend, la entrada queda bloqueada desde el inicio. Cada vez que llega una petición como “Necesito ver lo que se desplegó en sandbox, ¿cómo instalo la app?”, un desarrollador móvil tiene que detener lo que está haciendo para ayudar.

También evaluamos Appetize y BrowserStack. Pero entre (1) el costo que sube rápidamente a medida que crece el equipo y (2) el hecho de que los binarios de la app se suban a una nube externa, al final lo hicimos nosotros mismos con una Mac disponible.

Así nació tapflow: una herramienta open source y self-hosted para que cualquiera en el equipo pueda hacer QA móvil con simuladores de iOS y emuladores de Android desde el navegador. Quien lo usa no necesita instalar nada; solo abre el navegador. Y al ser self-hosted, los datos de la app tampoco salen de la Mac del equipo.

Lo más difícil al construirlo no fue la funcionalidad, sino la latencia. Si la pantalla se retrasa aunque sea medio compás, todos hacen un scroll una vez y cierran. Además, la pantalla del simulador pasa por el pipeline agent → relay → render del navegador, así que la latencia se acumula en cada tramo. Estas son las optimizaciones que fuimos haciendo para reducirla en esa ruta:

• Descartamos MSE. El buffer multimedia de <video> metía estructuralmente unos ~235 ms, así que lo reemplazamos con una arquitectura de 2 niveles: WebCodecs (contexto seguro) / WASM tinyh264 (HTTP plano). Declarando reorder=0 en el SPS, el tiempo de decode → present pasó de 267 ms a 2.5 ms. (medición con reloj único en localhost)
• Benchmarqueamos 4 decodificadores (tinyh264/FFmpeg/openh264), pero al final mantuvimos tinyh264 — FFmpeg solo ganaba en pantalla estática; en scroll perdía siempre y además el bundle era 11 veces más grande. El cuello de botella no era el decodificador, sino la carga/transmisión.
• Mejoramos la codificación por software de Android usando codificación por hardware en la Mac. El emulador no tiene codificador H.264 por hardware, así que scrcpy queda limitado por el codificador por software (22–29 fps). Sacamos los frames raw al host por gRPC y los codificamos con Mac VideoToolbox → 59 fps (con downscale). (captura base a 30 fps; en dispositivos físicos se sigue usando scrcpy)
• Inyección de toque en iOS sin WDA (inyectando directamente con la API HID de CoreSimulator), y el Mac Agent solo hace conexión saliente al relay (sin necesidad de reglas de firewall para tráfico entrante).

Limitaciones: el agente de iOS es solo para macOS, el toque usa Private API y podría romperse con actualizaciones de macOS, todavía está en v0.x y no soporta dispositivos físicos.

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

Licencia MIT
GitHub: https://github.com/jo-duchan/tapflow
Documentación: https://www.tapflow.dev

Si también han tenido problemas para acceder a simuladores, o tienen opiniones sobre enfoques de streaming de baja latencia o acceso mediante Private API, son bienvenidas.