AppleScript 的 IPC 核心是 Apple Events，一种高层语义化消息协议；仅支持脚本化的应用（如 Safari、Mail）可原生响应，非支持应用需依赖 System Events 的 UI 脚本模拟操作，远程控制则通过网络扩展 Apple Events 实现。
applescript 处理 macos 应用间通信（ipc）的核心机制是 apple events，它不是传统意义上的底层 ipc（如 mach ports 或 xpc），而是一套高层、语义化的进程间消息协议——专为用户任务设计，而非系统服务通信。
Apple Events 是 AppleScript 的底层通信基础
所有 tell application "Safari" 或 make new document 这类语句，最终都会被 Script Editor 编译成标准 Apple Event 消息，通过 macOS 的事件分发系统发送给目标应用。该消息包含：目标进程标识、事件类（如 core.open）、对象描述符（如 URL 字符串）、参数字典等。接收方应用需注册对应的 Apple Event 处理器（通常由其脚本词典 sdef 定义），才能响应。
这意味着：
- 只有声明支持 Apple Scripting（即实现了 Apple Event handler 并导出 sdef 或 applescript dictionary）的应用才能被原生控制；
- Finder、Mail、Calendar、Notes、Music 等原生应用均完整支持；
- 部分第三方应用（如 TextMate、OmniFocus）也主动适配，但 Electron 或 WebView 类应用（如 Slack、Figma）通常不支持，需退回到 UI 脚本方案。
UI 脚本：对非脚本化应用的“兜底”方案
当目标应用不响应 Apple Events 时，AppleScript 可借助 System Events 进程进行界面级操控。这不是真正的 IPC，而是 Accessibility API 的封装调用：
- 通过
tell application "System Events"查找窗口、菜单栏、按钮等 UI 元素； - 调用
click menu item "Save"或keystroke "v" using {command down}模拟用户操作； - 依赖系统“辅助功能”权限开启（需在「系统设置 > 隐私与安全性 > 辅助功能」中授权 Script Editor 或对应 App）。
这种路径绕过了应用逻辑层，稳定性较低（界面变动即失效），但覆盖范围广，是实际自动化中不可或缺的补充手段。
与其他 macOS IPC 机制的关系
AppleScript 不直接使用 Mach Ports、XPC 或 Distributed Notifications，但它和它们共存于同一 IPC 栈：
- Apple Events 本身运行在 Mach 内核之上，最终通过 Mach message 传递，但对开发者完全透明；
- XPC 更适合后台服务间高效通信（如插件与宿主），不面向终端用户任务；
- 如果你追求性能或深度集成，可跳过 AppleScript，用 Objective-C/C 直接调用
NSAppleEventDescriptor和AEProcessAppleEvent发送原生 Apple Events，省去脚本解释开销； - 剪贴板（
pasteboard）常作为 AppleScript 与 shell 脚本/LLM 工具链的轻量数据桥梁，例如用do shell script "pbcopy"交换文本。
远程 AppleScript：跨设备 IPC 的特殊形态
macOS 支持启用「远程应用程序脚本」（在「系统设置 > 通用 > 共享」中开启），允许其他 Mac 上的 AppleScript 通过网络发送 Apple Events 到本机。这本质是 Apple Events 的网络扩展，需满足：
- 双方运行 macOS 10.15+，且防火墙放行端口（默认 30300）；
- 本机设置中明确授权访问用户（支持“所有用户”或指定账户）；
- 远程脚本需使用
tell application "Finder" of machine "eppc://user@192.168.1.10"显式指定目标机器。
它适用于小团队内轻量协同（如远程触发构建、同步日历），但不建议暴露在公网，缺乏现代认证机制。
