Marathon Cloud runs your Android and iOS UI test suite on a pool of virtual devices, in parallel, and gives you a verdict fast enough to gate a pull request. You upload the app and test binaries with a CLI; the platform provisions devices, distributes tests, retries the flaky ones, and hands back a report, JUnit XML, video, and logs.
It is built on the open-source Marathon test runner, the execution engine used by teams whose apps reach hundreds of millions of users.
How a run works
Section titled “How a run works”- Submit:
marathon-cloud run android|ios|maestrouploads the binaries and starts the run. In CI this is one step; see CI/CD integration. - Plan: the scheduler parses the test list, looks up how long each test has taken in past runs, and sizes a device pool to finish in about 15 minutes.
- Execute: devices are provisioned fresh, the app is installed, and tests run in batches. Failed tests are retried on a different device.
- Report: the CLI exits
0or1, and the run is available in the console with per-test video, logcat or system logs, and Allure and JUnit reports. Artifacts can be pulled into CI with--outputormarathon-cloud download.
The 15-minute figure is a target the scheduler optimizes for, not a guarantee. Suites with very long individual tests, or a first run with no history, can take longer.
What it is good at
Section titled “What it is good at”- Gating pull requests: a full UI suite in one CI step, with a clear pass/fail exit code.
- Absorbing flakiness: retries happen per test, on a different device, and the report separates flaky from failed.
- Scaling without ops: no device farm to maintain, no shard configuration, no emulator images to keep current.
- Second-level billing: you pay for device time actually used; see pricing.
What it is not
Section titled “What it is not”- Not a physical device farm. Android runs on emulators and iOS on arm64 simulators. Hardware-specific behaviour is out of scope.
- Not a tunnel into your network. Backends under test must be reachable from the internet.
- Not a replacement for unit tests. It is built for instrumentation and UI suites that need a device.
Supported frameworks
Section titled “Supported frameworks”| Platform | Frameworks |
|---|---|
| Android | Espresso, UIAutomator, Kakao, Kaspresso, Cucumber, Flutter via Patrol; anything that runs as an instrumentation test. |
| iOS | XCTest, XCUITest, KIF, Flutter via Patrol. |
| Cross-platform | Maestro YAML flows on Android and iOS. |
Reports and artifacts
Section titled “Reports and artifacts”Every run produces an Allure report, JUnit XML, the Marathon HTML timeline, per-test screen recordings, and per-test device logs. See artifacts for the layout and retention.
Support
Section titled “Support”Email [email protected]. Include the run ID from the CLI output or console URL when reporting a problem with a run. Teams on an Enterprise plan get a shared Slack Connect channel after onboarding.
Next steps
Section titled “Next steps”- Quickstart: first run from your terminal in a few minutes.
- CI/CD integration: the GitHub Action, CircleCI orb, Bitrise step, and Docker image.
- Migrating from Firebase Test Lab or BrowserStack.