How 40 Lines of Code Sped Up iOS End to End Tests by over 50%
Article Summary
Wealthfront's iOS team cut E2E test time in half with just 40 lines of code. The culprit? A 1-second polling interval nobody questioned.
With 30k unit tests and nearly 1k E2E tests, Wealthfront's iOS team prioritized reliability over speed using XCTWaiter. But they discovered Apple's polling mechanism was blocking for a full second between checks, a design from the pre-M-series era that was killing performance.
Key Takeaways
- XCTWaiter polls every 1 second, blocking the test runner unnecessarily
- Custom polling at 0.1s intervals achieved 80% local speedup initially
- Exponential backoff (0.2s to 2s) prevented CI crashes from CPU overload
- Final result: 50% faster CI pipelines with stable parallel execution
By replacing Apple's outdated XCTWaiter with a custom polling mechanism using exponential backoff, Wealthfront achieved 50% faster E2E tests on CI and 80% locally.
About This Article
Wealthfront's iOS E2E tests had a tradeoff between speed and reliability. Immediate assertions ran fast but became flaky when tests ran in parallel. Waiting assertions with XCTWaiter were stable but slow because Apple's polling interval is locked at 1 second, which blocked the test runner.
The team built their own version of XCTWaiter with exponential backoff starting at 0.2 seconds and capping at 2 seconds. They also added a pre-check that skips polling entirely if the condition already passes. This prevented CPU overload on the M1 Mac Minis that were running four test processes at once.
The custom polling cut CI pipeline execution time in half while keeping tests stable in parallel environments. Local test runs saw 80% faster execution without crashes or reliability issues.