AppleScript vs Accessibility API: Four App Categories Where AppleScript Stops Working

Yes, on the part that drives UI. Apple's Technical Q&A QA1888 puts it plainly: 'System Events is just a wrapper around public [Obj]C system APIs, so you could bypass AppleScript and call those APIs directly.' Specifically, tell application System Events to click button X resolves to AXUIElementCopyAttributeValue and AXUIElementPerformAction calls under the hood. AppleScript also has language-level features (events, dictionaries, scripting additions) that are orthogonal to AX, but for GUI scripting the wrapper claim is accurate.

Three reasons. One: AppleScript GUI scripting routes every command through the System Events process, so the request crosses an AppleEvent boundary that can be denied (sandbox without scripting-targets entitlement, missing apple-events entitlement, no automation permission for the calling app). Two: AppleScript exposes only a subset of AX attributes and actions; kAXSelectedAttribute, kAXValueAttribute writes on read-only-via-keyboard fields, and several Catalyst-specific attributes have no AppleScript verb. Three: AppleScript GUI scripting often resolves clicks to synthetic events that go through the same input event tap that secure-input or Catalyst right-pane controls drop, while AXUIElementPerformAction(element, kAXPressAction) bypasses the input layer and asks the control directly.

Catalyst apps are iPad apps recompiled for macOS. They embed a UIKit view in an AppKit window. AppKit owns the title bar, sidebar, and toolbar; the right pane is a hosted UIKit surface. Synthetic CGEvents posted at coordinates inside that pane sometimes never become UIControl actions because the UIKit hit-testing path is reached through a different chain than the AppKit one. The control still appears in the accessibility tree because Catalyst bridges UIAccessibility into AX, and the kAXPressAction action still exists on it. So AXUIElementPerformAction works where a CGEventCreateMouseEvent does not. macos-use_press_ax_and_traverse at main.swift:1459 was added specifically because of this. Its docstring reads 'Often the only path that actuates buttons in those apps'.

No. The two paths cross different trust boundaries. AppleScript GUI scripting requires an AppleEvent from the calling process to System Events, then from System Events to the target app. A sandboxed calling process needs the com.apple.security.scripting-targets entitlement (with a per-app access group) or the temporary com.apple.security.temporary-exception.apple-events entitlement to make that first hop. The target also has to have published an SDEF or be reachable via System Events. Direct AX calls (AXUIElementCreateApplication, AXUIElementCopyAttributeValue, AXUIElementPerformAction) only require the standard Accessibility permission for the process making the calls. macos-use runs as a local Swift binary the user grants Accessibility permission to once, so the calling process is on the right side of that boundary. There is no AppleEvent hop.

macOS sets a process-wide secure-input flag when a password field, a Touch ID prompt, or a screen-locked keychain dialog is focused. While that flag is set, characters posted via CGEventCreateKeyboardEvent are silently dropped before reaching the focused control. AppleScript's keystroke command goes through the same path and silently drops too. AXUIElementSetAttributeValue with kAXValueAttribute writes through a different code path: it asks the AX provider to set the underlying string directly. So macos-use_set_value_and_traverse at main.swift:1442 can fill a text field whose synthetic typing was being dropped. The docstring is explicit: 'Bypasses the input event tap entirely. Use when typing fails (Catalyst right-pane fields, sandboxed/secure-input contexts).'

kAXSelectedAttribute is a boolean attribute on selectable controls (table rows in Catalyst tables, sidebar list entries, outline rows). The AX provider exposes it; setting it to true selects the row. There is no AppleScript verb that maps to it directly. tell application System Events to select row 3 of table 1 reaches a different code path that often does not actuate, and on Catalyst tables specifically the click that AppleScript synthesizes gets dropped. AXUIElementSetAttributeValue(rowElement, kAXSelectedAttribute, kCFBooleanTrue) actuates. macos-use_set_selected_and_traverse at main.swift:1477 exists for this case. Its docstring names the failure mode: 'Right primitive for Catalyst table rows, sidebar list entries, outline rows, and other selection-bearing controls that expose AXSelected but no AXPress action (where regular click is dropped and press_ax errors with kAXErrorActionUnsupported).'

Because most apps that ship on macOS are not Catalyst, are not sandboxed, do not use secure input, and do not have selectable Catalyst rows. For everything else, AppleScript is faster to write, has a higher-level vocabulary (tell application Mail to make new outgoing message), and a discoverable dictionary via Script Editor's Library. The AppleScript ecosystem also supports application-level scripting, where the app exposes its data model via SDEF and AppleScript talks to that model rather than the UI. AX cannot do that. The argument here is not that AppleScript is dead. It is that for an LLM driving arbitrary apps on a user's Mac, the bottom 5 percent of cases that AppleScript cannot reach is exactly the long tail an agent will hit, so the agent has to have direct AX as a fallback.

No. The server is pure Swift on top of ApplicationServices (the framework that ships AXUIElement) and CoreGraphics (for synthetic events when those still work). There is no NSAppleScript instance, no osascript shell-out, no AEPathDesc construction, no apple-events entitlement requested in the binary's Info.plist. The repo's Sources/MCPServer directory has 2056 lines in main.swift and 355 in InputGuard.swift, and none of them touch the AppleEvents framework. You can verify with grep AppleScript or grep osascript on the repo and you will get zero hits.

tell application System Events to select row 3 of table 1 of group 1 of window 1 of process "Messages" returns without an error. The row visibly does not get selected. There is no exception and no error string in the result. The next AppleScript command runs against the original row. This is the worst possible failure mode for an automation: silent, no signal, and the script keeps going as if the action succeeded. Direct AX surfaces an error code (kAXErrorAttributeUnsupported, kAXErrorActionUnsupported, or kAXErrorCannotComplete) that the calling code can branch on. macos-use treats those error codes as a recoverable signal: press_ax_and_traverse errors with kAXErrorActionUnsupported tell the agent to switch to set_selected_and_traverse instead.

Open Script Editor and try tell application System Events to set value of text field 1 of window 1 of process "Messages" to "hello". On Messages (Catalyst), the command returns without throwing and the field stays empty. Now run AXUIElementSetAttributeValue on the same field via Accessibility Inspector or the macos-use binary. The field fills. Same setup with the search field in Settings (Catalyst right pane), with any password input (secure-input context), and with the conversation list rows in Messages (Catalyst rows that expose AXSelected but no AXPress). Two minutes per case from a fresh Script Editor window. The error of omission is the whole signal.

Yes. The Swift MCP server has direct access to AXUIElement APIs, can post CGEvents with the right source and stateID, can install a CGEventTap to arbitrate input, and can fall back to AXUIElementSetAttributeValue when CGEvents are dropped. None of that is reachable from Python through AppleScript. py-applescript and appscript are wrappers around osascript, so they inherit every AppleEvent-boundary limitation. PyObjC could call AX directly but it carries the AppleEvents-and-NSWorkspace assumption stack with it. Swift on top of ApplicationServices is the smallest layer that can do the four cases above.