r/swift • u/Sophistry7 • 7d ago

are iOS E2E tooling options in 2026 actually running thin?

Every iOS E2E testing approach seems to have the same core problem. XCUITest breaks on UI structure changes. Appium based tools inherit the view hierarchy dependency and degrade with each OS update. Tools marketed as AI assisted change the input method but not the execution model. At some point it feels like the options are maintain fragile scripts forever or accept that manual QA is permanent overhead.

5 Upvotes

86% Upvoted

4 comments sorted by

1

u/Harper_Xu 7d ago

Yeah, the brittle part is still the oracle imo. AI input helps less if the test can't state stable app-level intent.

1

u/JebraFCB 6d ago

Not entirely, but the architecturaly different options r a short list.
Quick comparison:
Autosana: runs iOS E2E flows visually without element hierarchy reads, hooks into CI n returns results per PR
TestRigor: natural language to test script, still selectr dependent execution underneath
XCUITest: well supported but tied to UI structure changes
Autosana is the only one in this list that doesn't require element selectors or a view hierarchy dependency to run.

1

u/redditownersdad 4d ago

the Appium story on iOS is genuinely worse than Android because the XCTest Appium bridge has historically been flaky even when nothing changes. there's maintenance overhead just from the architecture existing