On iOS 18, when XCUITest encounters an "Application has not loaded accessibility" error after the 60 second timeout, it performs an undocumented auto-recovery ("Setting up automation session") instead of halting the test as documented. This leaves the XCUITest framework in a corrupted state, causing subsequent tests in the same session to fail with unexpected behavior. Expected Behavior (per Apple documentation): Any failure in the launch sequence will be reported as a test failure and the test will be halted at that point. Actual Behavior: XCUITest waits 60 seconds for accessibility to load Logs "Application has not loaded accessibility" error Instead of halting, performs "Setting up automation session" (auto-recovery) Test continues with corrupted framework state Subsequent tests in the same session fail with phantom element queries Steps Run XCUITest suite on a real iOS 18 device Have an app with moderately heavy initialization (e.g., synchronous network operations during bootstrap) Observe intermittent "accessibility not loaded" errors When error occurs, subsequent tests fail with unexpected behavior Test Logs Evidence First test (accessibility failure + recovery): t = 11.11s Wait for accessibility to load t = 71.14s Capturing diagnostic spindump t = 76.24s Assertion Failure: Application 'com.example.app' has not loaded accessibility t = 76.26s Setting up automation session ← Undocumented recovery t = 77.29s Tear Down Second test (corrupted state): t = 35.01s Tap "signin-button" t = 35.55s Waiting for "bannerButtonStackFirstItem" ← Query NOT in test code! t = 40.58s Assertion Failure: Failed to find element The second test executes element queries that do not exist in its source code, indicating leaked/corrupted state from the previous test's failed recovery. Note: The tearDown() method terminates the app but cannot reset the internal state of the XCUITest framework itself, so corruption persists across tests. We are observing this behavior consistently on iOS 18 real devices. We would like to know: Is this a known issue with XCUITest on iOS 18? Is anyone experiencing similar "accessibility not loaded" failures followed by auto-recovery? Is the "Setting up automation session" recovery behavior intentional or a bug? Is there a recommended workaround to prevent framework state corruption between tests?

Hello all, I wanted to get MXMetricPayload to analyse some App metrics. And for some reason the method func didReceive(_ payloads: [MXMetricPayload]) from mxMetricManager is not being executed. For this I created a Class: import MetricKit public final class MetricKitManagerImpl: NSObject, MetricKitManager { public static let shared: MetricKitManager = MetricKitManagerImpl(mxMetricManager: MXMetricManager.shared) private let mxMetricManager: MXMetricManager private init( mxMetricManager: MXMetricManager ) { self.mxMetricManager = mxMetricManager super.init() mxMetricManager.add(self) } deinit { mxMetricManager.remove(self) } public func didReceive(_ payloads: [MXMetricPayload]) { payloads.forEach { if let scrollHitchTimeRatio = $0.animationMetrics?.scrollHitchTimeRatio.value { sendToSomeWhere(scrollHitchTimeRatio) } } } } Then on the AppDelegate on didFinishLaunchingWithOptions I do: private(set) var metricsManager: MetricKitManager! func application( _ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil ) -> Bool { self.metricsManager = MetricKitManagerImpl.shared ... } With this setUp I am able to receive the debug playload (triggered from Xcode Menu. Debug -> Simulate Metrik Kit Payload). However, after using the app for some days, I did not receive any real payload. Did anyone experience this? What am I doing wrong? Thanks a lot in advance! Miguel Franco