Reported by @leo: trace mode "dramatically increases test running time, especially for CI" — 40-60s on iOS — and filmstrip: false does not help.
It cannot help: the cost is not the screencast. In trace mode every mapped action runs getPageSource() and takeScreenshot() (packages/core/src/action-snapshot.ts). They sit in one Promise.all, but a driver serialises per session, so that is two sequential round trips per action. On iOS the WDA page-source XML dump is the expensive half — often a second on its own. ~30 actions x ~1.5s lands on the number he measured.
The per-command screenshot is already skipped on native; this is what remains.
Options worth weighing:
- an option to skip the page-source probe on native (screenshot-only rows)
- full snapshot only for failing actions
- both, with the default chosen for CI rather than for debugging
Prerequisite: something to measure against
There is no example exercising the native mobile capture path, which is why the mobile bugs in this batch were only found by hand-building a harness — and why this issue cannot be closed honestly without one. Any option added here needs a real-device run before and after.
A working harness exists from that investigation: WDIO configs for Android (UiAutomator2) and iOS (XCUITest) driving BrowserStack's own public sample apps, in trace mode with no dashboard, verified end to end on a real Pixel 7 and a real iPhone 17. Landing it needs three decisions:
- where the app under test comes from (the sample apps have to be uploaded, so the app id cannot be hardcoded in a committed config)
- that credentials stay in the environment
- whether it runs in CI at all, or is documented as a manual harness like the other examples
Reported by @leo: trace mode "dramatically increases test running time, especially for CI" — 40-60s on iOS — and
filmstrip: falsedoes not help.It cannot help: the cost is not the screencast. In trace mode every mapped action runs
getPageSource()andtakeScreenshot()(packages/core/src/action-snapshot.ts). They sit in onePromise.all, but a driver serialises per session, so that is two sequential round trips per action. On iOS the WDA page-source XML dump is the expensive half — often a second on its own. ~30 actions x ~1.5s lands on the number he measured.The per-command screenshot is already skipped on native; this is what remains.
Options worth weighing:
Prerequisite: something to measure against
There is no example exercising the native mobile capture path, which is why the mobile bugs in this batch were only found by hand-building a harness — and why this issue cannot be closed honestly without one. Any option added here needs a real-device run before and after.
A working harness exists from that investigation: WDIO configs for Android (UiAutomator2) and iOS (XCUITest) driving BrowserStack's own public sample apps, in trace mode with no dashboard, verified end to end on a real Pixel 7 and a real iPhone 17. Landing it needs three decisions: