UI automation of menu bar apps XCUITest and Accessibility API
Parent: macOS App Testing and Release QA · Published reference · snapshot 2026-10-02
↓ Facts as markdownall context files
Source-anchored research for UI automation of menu bar apps XCUITest and Accessibility API. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- XCUITest and the Accessibility API (AXUIElement) are the same technology underneath; XCUITest is a restricted predefined layer. Raw AX use requires the host binary to be granted in System Settings > Privacy & Security > Accessibility before running. (medium confidence) [source]
- AX hierarchies can be wrong for NSHostingView-based UI; MacPaw uses a hit-test technique at coordinates to reach hidden layers. (low confidence) [source]
Problems, failure modes and limitations
- Apple does not support the Accessibility APIs in sandboxed apps. In a sandboxed menu bar app AXIsProcessTrusted returns false, the prompt never appears, and the app cannot be added in System Settings; with the com.apple.security.accessibility entitlement AX calls can still fail with .cannotComplete. A DTS engineer called this behaviour correct, in both local and TestFlight builds. (medium confidence) (verified as of 2026-10-02) [source]
Facts and statements
- XCUITest can find a menu bar status item with app.menuBars.statusItems and click it; a launch test can assert existence with app.menuBars.statusItems.firstMatch without checking isHittable. (medium confidence) [source]
- Content of a SwiftUI MenuBarExtra(.window) popover is not reliably in the accessibility tree under XCUITest; the safe launch guarantee is that the status item exists. Workaround: a DEBUG-only launch hook that opens the target window deterministically, or an NSStatusItem with an NSMenu and button accessibility label. (medium confidence) [source]
- If Xcode runs fullscreen, the menu bar is hidden and the status item test fails with 'Element StatusItem ... is not hittable'. Leave fullscreen before the run, or post a CGEvent mouse move near the top edge to reveal the menu bar (a reported, self-described ugly workaround). (low confidence) [source]
- On macOS Sequoia and later, XCTest UI tests prompt for a password to enable UI automation before each run, blocking CI. The accepted forum fix is `automationmodetool enable-automationmode-without-authentication`; disabling SIP and editing TCC did not help. This is a user-to-user answer, not an Apple statement. (low confidence) (verified as of 2026-10-02) [source]
- Sandbox-safe alternatives to AX window inspection (CGWindow list, ScreenCaptureKit) need Screen Recording consent; AppleEvents exceptions are temporary and unsuitable for App Store distribution. A network monitor should not add them for testing. (low confidence) [source]
- Headless CI use: a shared Xcode scheme lets xcodebuild test run the UI test target without opening Xcode; the runner/helper needs Accessibility consent on first use. (low confidence) [source]
Children
- No children recorded.