Watch the failed test.
See what went wrong.
Replay your iOS, tvOS and Android UI tests with video and structured logs from the app and test runner on one timeline. Group similar failures, spot flaky retries and spend less time reproducing what already happened.
iOS, tvOS & Android · PRO & ENTERPRISE · Hosted in Switzerland
Illustrative test run
More than a red cross and an assertion message
A failing UI test tells you where it stopped, not why. See the recording and captured activity leading up to the failure.
Replay the run, second by second
Scrub a video timeline synced with captured actions, queries, requests and logs. Click a log entry to jump to that moment, and share a link to it with your team.
A wall of red, reduced to its causes
Similar failures are grouped automatically across runs and executions. Annotate a group once with the root cause or an issue link and see it the next time it happens.
Flaky tests can’t hide
Tests that fail and then pass on retry are flagged as flaky in every execution, and each test case’s success rate shows whether it is stable, unstable or failing.
See the whole execution at a glance
One view of every device, every run and everything that went wrong while the suite was running.
- EnvironmentSTAGING 3.2
- App version4.3.0 (418)
- Test planComplete
- Run time48m 12s
- Success rate97.8%
- All 139
- Failures 3
- Flaky 6
- Efficiency 0.90
- Network 0.93
- Crashes 1
Illustrative execution
- Every device in one view. Each simulator, emulator or device gets a lane of its test runs. Hover for a screenshot, click to open the run.
- Efficiency insights. Resource allocation, average test duration and suite lengths reveal long suites that hold back parallel runs.
- Network quality during tests. An Appdex score and request breakdowns for everything the app called while the tests ran.
- Crashes and errors in context. App crashes and non-fatal errors from the execution are listed with their groups, and a crashed test shows the app’s stack trace next to the test’s.
Logs from both sides of the test
See what the test did and how the app responded, in one structured timeline instead of two raw console dumps.
- App and test runner, side by side. Integrate AppeliumFeedback in the app and enable the logs you need. App and test-runner logs share one timeline, each marked with its source. Android failures can also include Logcat.
- Every XCUITest action and query. On iOS, taps, typing, app launches with their arguments and environment, and element queries are captured automatically, with durations.
- Full requests and responses. Headers, bodies, status codes and timings. Jump from any request to its operation in network monitoring.
- CPU and memory next to the video. Spot spikes and memory warnings at the moment a test slows down or fails.
- Filter the noise. Narrow logs by source, level and domain, and switch between absolute and relative time.
- Sources App, Test
- Level Verbose
- XCTest Actions, Queries
- Time Relative
- AI
- AE
- T
Illustrative logs
The same synced timeline powers bug reports sent by your testers.
Turn a wall of red into a short list of causes
Forty failed runs rarely mean forty bugs. Appelium shows which ones share a cause and remembers what you learned about it.
- #27CheckoutTests.swift:84
XCTAssertTrue failed - “Total CHF 47.20” not found
SHOP-1432 · Voucher service times out on STAGING
- #31LoginTests.swift:42
Failed to tap “loginButton” Button: No matches found
- #12ImageUploadTests.swift:117
Asynchronous wait failed: Exceeded timeout of 10 seconds
Known photo library delay on fresh simulators
Illustrative data
- Similar failures, not just identical text. Failures of the same type in the same source file are matched by message similarity, after IDs, numbers, dates, URLs and tokens are masked.
- Annotate once. Add the root cause, a JIRA or Trello link or a workaround to a failure group or a test case. The next time it fails, the explanation is already there.
- Full history per group. See the first failure, the affected test cases and every failed run, filtered by environment, app version and test case. Track groups as Open, Closed or Ignored.
- Ready for AI agents. Through MCP, agents rank an execution’s failure groups, read a group’s history including flaky executions and the last passing run, and fetch logs, call stacks and screenshots.
Separate flaky tests from real regressions
Retries keep the pipeline green, but they also hide unstable tests. Appelium keeps the full picture.
- Flaky tests in every execution. A test that fails and then passes in the same execution, for example on retry, is counted as flaky. Iteration dots show the result of each attempt.
- Stability over time. Every test case has a success rate and a history of runs across environments and app versions.
- Compare with the last green run. Open the latest successful run of the same test and compare its video and logs with the failure.
- New or known? Each failure group shows when it first failed and how often it fails, so a new regression stands out from a familiar issue.
| Test case | Runs | Success rate |
|---|---|---|
| SearchTests. | 48 | 100% |
| LoginTests. | 50 | 94% |
| CheckoutTests. | 48 | 71% |
LoginTests.
Illustrative data · Stable 100% · Unstable 80% to <100% · Failing below 80%
Record your next run in minutes
Add the SDK to your UI test target and set it up once. Keep your existing test steps and assertions.
A video encoder built for tests
Appelium’s own low-footprint encoder records at a variable frame rate synchronized with app events and shows touches in the recording.
Set up once. Record each run.
Use a principal class on iOS and tvOS, or a shared base test class with AppeliumTestWatcher on Android. Tests using that setup are recorded without rewriting their assertions.
Built for parallel runs
Parallel simulator clones are grouped automatically. Across machines, devices or Test Orchestrator, pass one execution UUID to combine every run.
import AppeliumTestsKit
// Set as NSPrincipalClass of the UI test bundle
class UITestsSetup: NSObject {
override init() {
super.init()
AppeliumTests.start(apiKey: "<api key>")
AppeliumFeedback.setApplicationEnvironment(
name: "STAGING", version: "3.2"
)
}
}// Make your UI test classes extend BaseTest
open class BaseTest {
@Rule
@JvmField
val appeliumTestWatcher = AppeliumTestWatcher()
init {
AppeliumTests.Builder(
apiKey = "<api key>"
).build()
AppeliumTests.setTestExecutionEnvironment(
name = "STAGING", version = "3.2"
)
AppeliumTests.testPlanName = "Complete"
}
}Step-by-step guides for iOS, tvOS and Android, including test plans and parallel runs. Learn how failures grouping works. Suite green? Distribute the build to your testers.
Frequently asked questions
Which platforms and plans are supported?
UI test recording works with XCUITest on iOS and tvOS, and with Android instrumentation tests on API 21 and later. It is available on the PRO and ENTERPRISE plans.
Do I need to rewrite my tests?
Your test steps and assertions stay unchanged. Add AppeliumTests to the UI test target and initialize it in a principal class on iOS and tvOS. On Android, make your test classes extend a base class with AppeliumTestWatcher. The SDK records tests using that setup. Standard URLSession requests are captured automatically on iOS and tvOS; Android test-runner requests use explicit request and response logging.
How do I see the app’s own logs next to the test?
Integrate AppeliumFeedback into the app under test and enable the diagnostics you need. Captured app and test-runner logs appear on a shared timeline, each marked with its source. Available CPU and memory samples can be shown alongside the video. Console logging and network capture need the setup described in the platform guides.
How are test failures grouped?
Within an app, failures of the same type in the same source file are grouped when their messages are similar. Variable parts such as IDs, numbers, dates, URLs and tokens are masked before comparing. This helps collect related failures; it does not prove they share a root cause. Add your findings as an annotation and track each group as Open, Closed or Ignored.
How does Appelium detect flaky tests?
Within an execution, a test case that both failed and passed, typically on a retry, is counted as flaky. Across executions, each test case’s success rate classifies it as Stable (100%), Unstable (at least 80% but below 100%) or Failing (below 80%).
Stop re-running tests to find out why they failed
Replay your UI tests, group related failures and keep flaky tests in check.
You are in a good company - Join over 150 apps!
Over 150 apps in Switzerland choose to use Appelium.
👨💻 Latest content from our Engineering blog:
XPCService
Strongly typed bidirectional communication channel between UIApplication and XCUIApplication with powerful APIs and super fast performance.
More about XPCService
Screen Flow Pattern in UI tests
Robust and scaleable pattern for structuring UI tests. Highly reusable screen verification code with human readable test case code. All flows and interactions statically typed 🙌.
More about the Screen Flow Pattern
SnapshotQuery™
Learn about SnapshotQuery - our latest addition to AppeliumTests which radically improves the performance of your XCUITests while making them more stable and reliable at the same time.
More about SnapshotQuery
Early access and news
Be the fist one to know about all the exciting engineering posts and product announcements.