Running Mobile Tests Locally: Why We Built the Quash Mac App
Most QA infrastructure conversations start with the cloud. Scalable, on-demand, no hardware to manage. And for a lot of use cases, the cloud is the right answer.
But when we started building Quash's execution layer, we kept running into a problem that cloud-first tooling consistently papers over: local devices are where the most important testing happens, and almost nothing makes that easy.
So we built the Mac app. Here's why — and what it took.
Why Cloud-Only Mobile Testing Isn't Enough
The promise of cloud device testing is simple: a browser-accessible grid of real devices, available on demand, no hardware required. Services like BrowserStack and LambdaTest have made this work reasonably well for web testing. For mobile, the picture is messier.
Why Do Cloud Device Farms Limit ADB Access?
Android Debug Bridge — the tool that lets you actually communicate with an Android device at the level required for serious automation — isn't available in most cloud testing environments in any meaningful way. You can trigger test runs, but the low-level device control that a vision-based execution engine like Mahoraga requires is either locked down, abstracted away behind a proprietary layer, or simply unavailable. If your execution engine needs to read the accessibility tree, respond to screen state in real time, and install agents directly on the device, you need real ADB access. Cloud grids rarely give you that cleanly.
Private devices are the second wall. If you want a dedicated real device in the cloud — one that isn't shared across dozens of teams, one where you control what's installed, one where you can trust the environment — you're typically looking at around $1,000 per device per month on the major platforms. For a team testing across six device configurations, that's $6,000 a month before you've written a single test case. For most teams, that number ends the conversation before it starts.
The result is a gap that most QA tooling quietly ignores: teams that need real, controlled, low-latency device access either pay a premium they can't sustain, or they give up on meaningful automation and stay manual.
Get the Mobile Testing Playbook Used by 800+ QA Teams
Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.
What We Built Instead: A Local-First, Cloud-Hybrid Architecture
Rather than accept that trade-off, we approached the infrastructure problem differently. The architecture we settled on is a local-first, cloud-hybrid model — and it starts with the Mac app as the primary execution surface.
For cloud coverage, we host emulators on AWS. This gives us control over the environment, the ability to pre-install Mahoraga, and the flexibility to scale capacity without the per-device pricing model that makes dedicated cloud devices prohibitive. Emulators in a controlled cloud environment hit a different cost curve than dedicated real hardware — and for the majority of test scenarios, especially during development and CI runs, they're more than sufficient.
For local execution, the Mac app connects directly to whatever devices the team already has: physical Android phones and tablets via USB, Android emulators running locally on the machine. No cloud dependency, no per-minute billing, no queue. If you have a device and a USB cable, you can run a test.
The result is a hybrid that covers both ends: cloud emulators for scale and CI integration, local real devices for the precision and trust that only comes from hardware you control. Teams don't have to choose one model — they work in parallel, and results from both surfaces feed into the same unified workspace.
How Is the Local + Cloud Hybrid Approach Different from Just Using a Cloud Farm?
Cloud farms give you access to devices you don't own, over a connection you don't control, at a per-minute cost that adds up. The local + cloud hybrid gives you both options: use your own hardware (at zero marginal cost per run) for the testing that benefits from it, and cloud emulators (at a lower price point than dedicated cloud devices) for CI scale. The two surfaces are interchangeable from the execution perspective — Mahoraga doesn't behave differently on local vs cloud.
The Technical Challenges: What Building This Actually Involved
Building a desktop app that manages live device connections, runs a vision-based AI execution engine, and streams results back to a cloud workspace is not a small surface area for things to go wrong.
Performance on lower-end machines was one of the harder problems to solve cleanly. Mahoraga — the execution engine that reads the live screen, interprets UI state, and decides the next action — does meaningful compute work per step. On a high-spec MacBook Pro, that's invisible. On a machine with 8 GB of RAM running the app alongside a full emulator and a development environment, it surfaces quickly as lag, dropped frames, or execution timeouts.
The work here was largely about where the compute lives. We moved as much of the heavy processing off the local machine as possible — model inference, report generation, and execution logging all happen on the Quash backend, not on the machine running the app. What stays local is the device communication layer: ADB, screen capture, accessibility tree reads, and the lightweight coordination between those and the cloud-side execution logic. The app becomes a thin but reliable bridge rather than a full execution environment. That distinction matters a lot for teams that aren't running the latest hardware.
How Device Connectivity Works: USB and SSH Tunnels
The connection model varies depending on whether you're running local or cloud.
For local devices: plug in your Android device via USB, enable developer mode and USB debugging, and the Mac app detects it automatically. Mahoraga installs itself on the device during first connection — no manual APK installation, no configuration steps. If the device disconnects mid-run, the app attempts auto-reconnect before marking the session as interrupted.
For cloud devices: the connection is handled via SSH tunnels between the Mac app and the cloud-hosted emulator instances. From the user's perspective, this is invisible — you click Connect in the device panel and a cloud device is assigned and ready within seconds. Under the hood, the tunnel gives Mahoraga the same direct device communication channel it has over USB locally. The cloud device behaves like a local one. The test doesn't know the difference.
What Real Execution Without Infrastructure Setup Actually Looks Like
Taken together, the Mac app and the connectivity model it supports unlock something that sounds obvious but is surprisingly rare in mobile QA tooling: real test execution with zero infrastructure setup.
Any engineer on the team can connect a device they have on hand and run a full automated test in under five minutes. No AWS account to configure, no device farm subscription to negotiate, no framework to install, no environment variables to set. The app handles Mahoraga installation, device calibration, and the connection to the Quash workspace automatically. What's left is writing the test.
For QA leads and engineering managers: device availability stops being a bottleneck. Local devices that were previously used only for ad-hoc manual testing become first-class execution targets. The physical device on a QA engineer's desk can now run a structured regression suite automatically, produce a full execution report with screenshots and an AI-written summary, and feed results back into the same workspace the whole team shares.
For CTOs evaluating mobile QA infrastructure: the choice between "pay $1,000/device/month for cloud access" and "use hardware we already own" changes the economics of automation entirely. Teams that previously couldn't justify the infrastructure cost of serious mobile automation can now run it on existing hardware, with cloud emulators filling the gaps where local coverage doesn't extend.
The Mac app isn't the headline feature. It's the foundation that makes everything else possible. Getting device connection right, at zero friction and zero infrastructure overhead, is what actually moves mobile QA from "a thing the team plans to set up" to "a thing the team uses every day."
Frequently Asked Questions
Can I run Android tests locally on a Mac without a cloud device farm? Yes. The Quash Mac app connects to physical Android devices via USB or local Android emulators and runs full test execution locally using the Mahoraga engine. No cloud dependency, no per-minute billing. You need the device and a USB cable.
How does the Quash Mac app connect to Android devices? Physical devices connect via USB with developer mode and USB debugging enabled — the app detects them automatically and installs Mahoraga on first connection. Cloud devices connect via SSH tunnel; from the user's side it's a single click in the device panel.
How much does cloud device testing cost compared to local testing with Quash? Dedicated cloud device slots on major platforms run approximately $1,000 per device per month. Local testing with the Quash Mac app uses hardware you already own — the marginal cost is $0 per test run. Quash's cloud emulators (hosted on AWS) are available for CI scale at a lower price point than dedicated cloud hardware.
Does the Quash Mac app support iOS testing? Yes — Mahoraga runs on iOS simulators on Mac (iOS 15–17). Physical iOS device support is not yet available. Android physical devices and emulators are fully supported.
What are the minimum requirements for the Quash Mac app? macOS with at least 8 GB RAM is recommended for running local execution alongside a full Android emulator. Most modern Macs comfortably meet this. The compute-intensive parts of Mahoraga's execution run on Quash's backend, minimising local resource usage.
