Tapflow

A self-hosted Appetize / BrowserStack alternative for mobile QA teams

Run iOS simulators and Android emulators in any browser — no toolchain setup, no device pool, no cloud uploads.
Your builds, streams, and recordings stay on infrastructure you control.



<strong>No WebDriverAgent</strong>
&nbsp;·&nbsp;
<strong>2-line setup</strong>
&nbsp;·&nbsp;
<strong>MIT</strong>












📖 Docs
&nbsp;·&nbsp;
🚀 Quick Start
&nbsp;·&nbsp;
🎥 Demo
&nbsp;·&nbsp;
🎬 Setup

https://github.com/user-attachments/assets/dbba8bde-74b6-4fb9-bdb6-3919bc4295c4

Streams over H.264 with a zero-buffer decoder (no MSE) — latency measurements ↗

v0.x, actively developed — backward-compatible by default; breaking changes are rare and always noted in the changelog. Roadmap →

---

Why tapflow?

Mobile QA usually depends on access to simulators, emulators, or physical devices — and that access is uneven across a team.

For mobile developers it means opening Xcode or Android Studio on a Mac. For everyone else, it often means asking a mobile developer every single time:

Backend developer — "How do I install the sandbox build to check what was deployed?"

Product manager — "I keep installing and removing versions just to compare behavior."

Designer — "I need to check the layout across screen sizes, but I don't have the right devices."

Physical devices add their own overhead — OS-version coverage, availability, charging, storage, handoff. Cloud simulator services solve access, but they require uploading internal builds to a third-party service and paying for remote devices while your own Macs can already run the same simulators.

We hit this exact problem, so we built tapflow.

Solution	The catch
Appetize / BrowserStack	Recurring cost — and app builds are uploaded to a third-party cloud
Physical devices	Cost, availability, OS coverage, management overhead
Xcode / Android Studio	Each teammate needs a Mac and a full mobile toolchain
tapflow	Reuse your own Macs — data stays on infrastructure you control, and the whole team does QA from a browser

How it works

tapflow connects three parts:

1. A self-hosted relay (Linux or Mac) — also serves the dashboard on the same port, so there's no separate web server.
2. A macOS agent that drives the iOS Simulator and Android emulator — it connects outbound to the relay (no inbound firewall rules) and injects iOS touch directly, without WebDriverAgent.
3. A browser dashboard for the rest of the team — pick an available device and interact with it in real time while the simulators keep running on your Macs.

Browser (your team)  ←─ WebSocket ─→  Relay Server  ←─ WebSocket (outbound) ─→  Mac Agent
                                    (Linux / Mac)                           (iOS · Android)

What tapflow is not