Eine QA-Umgebung mit iOS/Android-Simulatoren im Browser bauen — warum wir MSE verworfen haben

Wenn man in einem Team mobile Apps entwickelt, hat man das vermutlich mindestens einmal erlebt. Es gibt nie genug Testgeräte, und es ist schwer, verschiedene OS-Versionen gleichmäßig abzudecken. Nimmt man stattdessen Simulatoren, braucht man Xcode oder Android Studio — für Teammitglieder ohne mobile Entwicklungsumgebung wie Produktmanager, Designer oder Backend-Entwickler ist der Einstieg damit praktisch blockiert. Und bei Anfragen wie „Ich müsste mir mal ansehen, was in der Sandbox deployed wurde — wie installiere ich die App?“ müssen mobile Entwickler jedes Mal ihre eigentliche Arbeit unterbrechen und helfen.

Wir haben uns auch Appetize und BrowserStack angesehen. Ausschlaggebend dagegen waren aber (1) die mit wachsender Teamgröße schnell steigenden Kosten und (2) die Tatsache, dass App-Binaries dafür in eine externe Cloud hochgeladen werden müssen. Also haben wir es einfach selbst auf einem ungenutzten Mac gebaut.

Das Ergebnis ist tapflow — ein Open-Source-Self-Hosting-Tool, mit dem jeder im Team mobile QA mit iOS-Simulatoren und Android-Emulatoren direkt im Browser machen kann. Auf der betrachtenden Seite muss nichts installiert werden, man öffnet einfach den Browser, und durch Self-Hosting verlassen App-Daten den Team-Mac nicht.

Die größte Herausforderung beim Bau war nicht die Funktionalität, sondern die Latenz. Wenn das Bild schon nur einen halben Takt hinterherhinkt, scrollen die Leute einmal und machen es sofort wieder zu. Dazu kommt, dass sich beim Simulatorbild auf jeder Station der Pipeline agent → relay → browser render zusätzliche Verzögerung aufsummiert. Das sind die Punkte, die wir auf diesem Pfad zur Latenzreduzierung herausgearbeitet haben:

• Wir haben MSE verworfen. Da der Medienpuffer von <video> strukturell etwa ~235 ms verursacht hat, haben wir ihn durch ein 2-Tier-Setup aus WebCodecs (Security Context) und WASM tinyh264 (Plain HTTP) ersetzt. Durch die Deklaration von reorder=0 im SPS sank decode→present von 267 ms auf 2,5 ms. (gemessen mit einem einzelnen localhost-Takt)
• Wir haben 4 Decoder (tinyh264/FFmpeg/openh264) benchmarked, sind aber am Ende bei tinyh264 geblieben — FFmpeg war nur bei Standbildern besser, verlor beim Scrollen aber jedes Mal und brachte zudem ein 11-fach größeres Bundle mit. Der Bottleneck war nicht der Decoder, sondern Last/Übertragung.
• Wir haben Android-SW-Encoding auf HW-Encoding des Macs verbessert. Im Emulator gibt es keinen HW-H.264-Encoder, deshalb hängt scrcpy am SW-Encoder fest (22–29 fps). Wir geben die Rohframes per gRPC an den Host weiter und encodieren dort mit Mac VideoToolbox → 59 fps (downscaled). (standardmäßig 30-fps-Capture, auf echten Geräten weiter scrcpy)
• Touch für iOS ohne WDA (direkte Injektion über die CoreSimulator HID API), Mac Agent verbindet sich nur outbound mit dem Relay (keine inbound-Firewall-Regeln nötig).

Einschränkungen: Der iOS-Agent ist nur für macOS, Touch basiert auf einer Private API und kann durch macOS-Updates kaputtgehen, noch v0.x, keine Unterstützung für echte Geräte.

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

MIT-Lizenz
GitHub: https://github.com/jo-duchan/tapflow
Dokumentation: https://www.tapflow.dev

Wer schon einmal mit dem Zugriffsproblem bei Simulatoren zu tun hatte oder Meinungen zu Low-Latency-Streaming bzw. zu diesem Private-API-Ansatz hat: Feedback ist willkommen.