macOS 的辅助功能（Accessibility）API 是开发者实现窗口管理、自动化操作和系统级交互的核心接口。然而，当开发者试图将依赖这些 API 的应用提交至 Mac App Store 时，往往会遭遇意料之外的审核拒绝。这种冲突并非技术缺陷，而是 Apple 平台安全策略与开发者意图之间的系统性张力。
冲突案例：TilesWM 的审核困境
2025 年 10 月，开发者 Denis Steinhorst 在 Apple Developer Forums 分享了他的经历：经过六个月全职开发，他完成了窗口管理器应用 TilesWM 的全部功能实现、文档撰写和营销准备，却在 App Store Connect 验证阶段被系统拦截。错误信息清晰而决绝：
Validation failed
Invalid Code Signing Entitlements. Your application bundle's signature
contains code signing entitlements that are not supported on macOS.
Specifically, key 'com.apple.security.accessibility' ... is not supported.
Validation failed
App sandbox not enabled. The following executables must include the
"com.apple.security.app-sandbox" entitlement with a Boolean value of true...
更令开发者困惑的是，同类竞品如 Magnet、Divvy、BetterSnapTool 等早已在 Mac App Store 上架销售，功能与 TilesWM 几乎一致。这种 "同案不同判" 的现象揭示了平台治理中一个鲜为人知的灰色地带。
技术边界：沙箱与辅助功能 API 的根本不兼容
Apple 官方文档《Protecting user data with App Sandbox》明确列出了沙箱化应用被禁止的活动：
"Certain activities are forbidden by the operating system when an app runs in a sandbox ... The restricted activities are: ... Use of accessibility APIs in assistive apps."
这一限制的技术根源在于辅助功能 API 的工作机制。通过 AXUIElement 系列接口，应用可以遍历系统内所有窗口的层级结构、读取其他应用的界面元素、模拟用户输入事件，甚至修改窗口的几何属性。这种跨进程、跨应用边界的操作能力，与沙箱设计的核心目标 —— 最小权限原则和进程隔离 —— 存在本质冲突。
即使应用在系统偏好设置的 "隐私与安全" 中获得了用户明确授权的辅助功能权限，沙箱策略仍会在运行时层面阻止 API 调用。这意味着开发者无法通过用户授权来绕过沙箱限制，两者是互斥的排他关系。
判定机制：双重锁定的政策架构
Apple DTS（Developer Technical Support）工程师在处理此类问题时，通常会明确区分两个层面：
技术层面：沙箱与辅助功能 API 的不兼容是操作系统层面的硬性约束，不存在通过 entitlement 配置或临时例外授权来绕过的可能。工程师指出，com.apple.security.accessibility 并非有效的 entitlement 键值，开发者无法通过声明该权限来获得沙箱内的辅助功能能力。
政策层面：App Store Review Guidelines 第 2.4.5 (i) 条规定，通过 Mac App Store 分发的应用必须启用沙箱。这一政策自 macOS 10.7.3 时代开始强制执行，形成了技术限制与政策要求的 "双重锁定"。
这种架构设计意味着，即使开发者能够证明其使用辅助功能 API 的意图完全正当（如窗口管理、无障碍辅助等），也无法通过审核流程。系统层面的技术限制已经预先排除了政策层面的讨论空间。
灰色地带：祖父条款造成的市场壁垒
TilesWM 案例中最具争议的焦点在于 grandfathered apps 的存在。Magnet、Divvy 等竞品确实在使用辅助功能 API 操控其他应用窗口，且它们确实在 Mac App Store 上架销售。
Apple 工程师对此的解释是：沙箱强制要求是在 macOS 10.7.3（约 2012 年）左右引入的。在此之前已在 App Store 上架的应用可以继续以非沙箱状态存在，形成事实上的 "祖父条款" 豁免。这意味着新进入者面临与既有竞争者完全不同的准入条件，造成了特定品类（窗口管理器、系统工具等）的市场准入壁垒。
这种治理模式在平台经济中并不罕见，但其技术实现方式 —— 通过沙箱策略而非单纯的审核指南 —— 使得竞争壁垒具有了不可逾越的刚性。
可行策略：直接分发与功能重构
面对这一结构性限制，开发者可选择的应对路径有限但明确：
直接分发（Developer ID Signing）：绕过 Mac App Store，通过开发者证书直接签名分发。这是 Apple 工程师明确建议的 "唯一前进路径"。直接分发保留了应用使用辅助功能 API 的完整能力，但需要开发者自行解决分发渠道、支付处理、更新机制等基础设施问题。
功能重构：将应用功能限制在沙箱允许的范围内。例如，窗口管理器可以仅操作应用自身的窗口，或依赖用户显式触发的自动化脚本（通过 Shortcuts、AppleScript 等机制）。这种方案通常意味着核心功能的实质性阉割。
临时例外申请：虽然理论上存在向 Apple 申请特定沙箱例外的可能，但针对辅助功能 API 的例外申请在实际中几乎从未获批。工程师建议通过 Feedback Assistant 提交功能请求，但这属于长期博弈而非即时解决方案。
平台治理的权衡与开发者困境
macOS 辅助功能 API 与沙箱策略的冲突，本质上是平台安全与开发者灵活性之间的权衡。Apple 选择以沙箱作为不可逾越的底线，将涉及跨应用控制的高风险能力排除在官方分发渠道之外。这一策略在降低恶意软件风险的同时，也限制了合法创新者的市场准入。
对于依赖系统级交互能力的工具类应用开发者而言，这意味着必须在产品定位初期就做出关键决策：接受沙箱限制并重构功能边界，或放弃 App Store 的便利性选择直接分发。无论哪种选择，都需要对平台治理逻辑有清晰认知，避免在开发后期遭遇 TilesWM 式的沉没成本困境。
参考来源
- Apple Developer Forums: Unable to submit my macOS window-manager app (thread 805556)
- Apple Developer Forums: Sandboxing problem (thread 46228)
- Apple Documentation: Protecting user data with App Sandbox
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。