Apple 因我使用辅助功能 API 拒绝了我的听写应用

原文 ↗ Hacker News 讨论 ↗

App Store 拒绝与辅助功能 API

  • 该应用的 Mac App Store 版本因使用辅助功能（AX）API，通过合成按键（CGEventPost）自动粘贴到其他应用中，被依据指南 2.4.5 拒绝。
  • 一个删减版的 App Store 版本只写入剪贴板（不申请 AX 权限；由用户按 Cmd+V）则通过了审核。
  • 功能完整的版本通过开发者网站直接分发，并由 Apple 签名和公证，因此限制只是 App Store 级别的，而非整个操作系统层面的。
  • 一些人提到类似经历：基于辅助功能的听写或自动化应用在 macOS 上常被拦下，但在 iOS 上有时能通过，反之亦然，审核结果并不一致。

安全、隐私与 Apple 的理由

  • 许多评论者认为 Apple 严格管控辅助功能 API 是合理的，因为它实际上赋予了对整个系统的控制权：按键、光标、截图以及跨应用数据路径。
  • 担忧包括恶意应用可能向敏感字段（如银行网站）粘贴内容或窃取数据。一些人强调，天真的用户会太容易授予这些权限。
  • 另一些人认为，用户本来就必须明确授予 AX 权限，因此应该允许他们选择强大的工具；禁止整类应用被视为越权，甚至可能带有反竞争色彩。

辅助功能 API 的设计

  • 多条评论批评该 API 过于宽泛；它迫使应用申请比实际需要更多的权限。
  • 一种建议的修复方案是：把 AX 拆分为范围更窄、可分别授予的能力（例如粘贴、截图、光标控制），而不是一个“超能力”式权限。
  • 反方观点是：对于某些残障用户来说，通过单一接口获得对任意对象的完全控制正是所需要的，因此拆分时不能让启用辅助技术变得过于繁琐。

平台、围墙花园与替代方案

  • 这个案例引发了更广泛的封闭生态争论。一些人把它看作 Apple 控制欲强、规则不一致的 App Store 机制的又一例证，并主张开放平台和侧载。
  • 另一些人则为精选商店辩护，认为它们对安全很有价值；如果用户不喜欢这些限制，可以选择别的操作系统。
  • 也有人推荐 Linux 桌面，认为其灵活，支持 flatpaks、应用商店以及良好的硬件支持，但也承认兼容性仍有缺口（例如 Microsoft Office、某些游戏），而且对许多用户来说迁移成本不低。

变通方案、商业影响与开发者策略

  • 建议包括：
    • 把 Mac App Store 当作更强大直接下载版本的“发现 + 许可证锚点”。
    • 提供受限/试用版 App Store 构建，再将用户升级到商店外的单独“专业版”应用。
  • 有人分享他们会维护分别对应“App Store 安全版”和“完整版”的工具，尤其是那些依赖 AX 的工具。
  • 对不透明且执行不一致的规则感到沮丧的同时，也有务实的接受：许多开发者预期会经历多次拒绝，并学会围绕 Apple 的限制来设计。