Até criar um ambiente de QA com simulador iOS/Android no navegador — por que abandonamos o MSE

Se você trabalha em um time que desenvolve apps mobile, provavelmente já passou por isso ao menos uma vez. Sempre faltam dispositivos de teste, e também é difícil cobrir bem diferentes versões de sistema operacional. Mas, se a ideia é usar simuladores, aí é preciso ter Xcode ou Android Studio, então membros do time sem ambiente de desenvolvimento mobile — como PMs, designers ou desenvolvedores de servidor — acabam barrados logo na entrada. Sempre que chega um pedido como "Preciso dar uma olhada no que foi publicado no sandbox, como instalo o app?", um desenvolvedor mobile precisa parar o que está fazendo para ajudar.

Também avaliamos Appetize e BrowserStack. Mas (1) o custo sobe rápido conforme o time cresce e (2) nos incomodava o fato de os binários do app serem enviados para uma nuvem externa, então acabamos construindo a solução nós mesmos com um Mac ocioso.

O resultado foi o tapflow — uma ferramenta open source e self-hosted para que qualquer pessoa do time possa fazer QA mobile no navegador com simulador de iOS e emulador de Android. Quem vai usar não precisa instalar nada, basta abrir o navegador, e por ser self-hosted os dados do app não saem do Mac do time.

A parte mais difícil durante o desenvolvimento não foi a funcionalidade, e sim a latência. Se a tela atrasa meio tempo de batida, todo mundo testa um scroll e fecha a janela. Além disso, a tela do simulador passa pelo pipeline agent → relay → renderização no navegador, então a latência vai se acumulando em cada etapa. Estas foram as principais otimizações que fizemos nesse caminho:

• Abandonamos o MSE. Como o buffer de mídia do <video> introduzia estruturalmente ~235ms, trocamos por uma arquitetura em 2 camadas com WebCodecs (contexto seguro) / WASM tinyh264 (HTTP sem TLS). Declarando reorder=0 no SPS, o tempo de decode→present caiu de 267ms para 2,5ms. (medição em clock único no localhost)
• Benchmarks com 4 decodificadores (tinyh264/FFmpeg/openh264), mas no fim mantivemos o tinyh264 — o FFmpeg só ganhava em tela estática, perdia sempre em scroll e ainda gerava um bundle 11 vezes maior. O gargalo não era o decodificador, e sim carga/transmissão.
• Melhoramos a codificação por software do Android com codificação por hardware do Mac. Como o emulador não tem encoder H.264 por hardware, o scrcpy fica limitado ao encoder por software (22–29fps). Extraímos os frames brutos via gRPC para o host e codificamos com o VideoToolbox do Mac → 59fps (com downscale). (captura padrão em 30fps; em dispositivos reais continua scrcpy)
• Toque no iOS sem WDA (injeção direta via CoreSimulator HID API), e o Mac Agent faz apenas conexão de saída para o relay (sem necessidade de regra de firewall de entrada).

Limitações: o agente de iOS é exclusivo de macOS, o toque usa Private API e pode quebrar em atualizações do macOS, ainda está em v0.x e não há suporte a dispositivos reais.

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

Licença MIT
GitHub: https://github.com/jo-duchan/tapflow
Documentação: https://www.tapflow.dev

Se você já enfrentou problemas de acesso a simuladores, ou tem opiniões sobre streaming de baixa latência / abordagem com Private API, comentários são bem-vindos.