# UI automation of menu bar apps XCUITest and Accessibility API > Source-anchored research for UI automation of menu bar apps XCUITest and Accessibility API. Run status: COMPLETED. Parent: [macOS App Testing and Release QA](https://llms-explorer.com/tree/macos-app-testing-and-release-qa/) · 3 facets · 9 facts · page: https://llms-explorer.com/tree/ui-automation-of-menu-bar-apps-xcuitest-and-accessibility-api/ ## 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](https://research.macpaw.com/publications/how-to-parse-macos-app-ui) - AX hierarchies can be wrong for NSHostingView-based UI; MacPaw uses a hit-test technique at coordinates to reach hidden layers. (low confidence) — [source](https://research.macpaw.com/publications/how-to-parse-macos-app-ui) ## 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](https://developer.apple.com/forums/thread/794253) ## 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](https://github.com/tomada1114/hintjump/pull/32) - 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](https://github.com/dylblake/NoteSide/pull/11) - 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](https://developer.apple.com/forums/thread/773715) - 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](https://developer.apple.com/forums/thread/793307) - 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](https://developer.apple.com/forums/thread/794253) - 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](https://github.com/dylblake/NoteSide/pull/11)