jo-duchan / 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.
 No WebDriverAgent 
  · 
 2-line setup 
  · 
 MIT 
 📖 Docs 
  · 
 🚀 Quick Start 
  · 
 🎥 Demo 
  · 
 🎬 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.
 [code] 
## What tapflow is not
tapflow doesn't replace native mobile development tools. Mobile developers still use Xcode, Android Studio, and their build tooling. tapflow makes the *running* simulators and emulators accessible to the rest of the team through a browser, and it is not a device farm. It does have an automated QA axis — a deterministic flow runner and an MCP server for LLM agents — but wiring in external automation frameworks