Agentic Mobile QA that works like a human, not a script.

Spur connects to CI/CD through GitHub Actions, GitLab CI/CD, and a webhook for other providers such as Jenkins or CircleCI, so test plans can run on each pull or merge request and block a merge when something breaks. Tests run in parallel, with separate concurrency for iOS and Android so mobile runs scale alongside the rest of your suite.

Every run produces a step-by-step visual replay: a screenshot of each screen next to the action the agent took on it, so you can see exactly where and why a run diverged. Console log data is captured during native runs as well, so you have more than the visual trace to work from. That evidence is usually enough to confirm whether a failure is a genuine product issue or a test that needs a small adjustment.

Because tests describe intent in plain English rather than pointing at specific elements, a layout change that a person would still understand usually will not break them. Tests are designed to fail when the user story or the behavior actually changes, not when the code underneath does. Your team owns the tests and can edit them in plain language, with no scripting required to keep them running.

Some journeys pass through a screen or sheet that sits outside your app's own UI, such as a verification step. Because the agent drives the full device session and acts on whatever is on screen, it can continue through these moments the way a person would, rather than stopping at your app's boundary. When a flow needs a verification code, the agent can read it in-flow through the built-in email step.

Instead of guessing distances, you tell the agent what to look for and it scrolls until that element appears, for example "scroll down until the Add to Cart button is visible." When you point it at a specific container, it scrolls inside that container, so a feed inside a card or a list inside a tab moves on its own. You can also control motion by position, percentage, pixel value, or intensity.

Yes. Spur can open a specific screen directly through your app's URI scheme (for example, yourapp://products/12345). This is useful for jumping straight to the screen under test and for confirming your app handles incoming links correctly. You will find your scheme in Info.plist on iOS or AndroidManifest.xml on Android. Pair a deep link with a wait or verify step so the destination has time to load.

Yes. Because the agent works from what is on screen rather than from platform-specific locators, it is framework-agnostic and works with native apps regardless of how they were built. Hybrid apps with embedded WebView content are supported as well.

Native tests run on cloud-hosted iOS Simulators and Android Emulators, so iOS builds need to be Simulator builds. You can pick from a range of devices and current OS versions, including recent iPhones (the iPhone 15 through 17 families and iPhone SE), iPads (Pro, Air, and mini), and Pixel devices (Pixel 4a, 4 XL, 5, and 6 Pro). Running on managed virtual devices keeps runs consistent and easy to parallelize, with no physical device lab to maintain.

You upload your build to a native environment, then select it when you run a test. Spur accepts .apk for Android and .ipa or .app.zip for iOS. A single test can target iOS, Android, or both.

No. Spur does not rely on XPaths, selectors, or added accessibility hooks. Every run is an AI run: the agent looks at the screen and interacts with it the way a person does. You describe the test in plain English, so the build you test is the same build you ship.

No. Spur tests your app as a finished build. You upload your compiled iOS and Android binaries, and the agent runs against them as a black box, the same way a real user would. There is nothing to wire into your repository, and Spur requires zero access to your codebase.