应对“拒绝”：当 Apple 拒绝你以无障碍为驱动的应用时

对于许多开发者来说，编写代码是一种热情的投入，但对于 Rene Zelaya 来说，这变成了一场身体上的挣扎。在经历了多年的重度键盘使用后，Zelaya 患上了进行性手部损伤，这使得持续打字几乎变得不可能。这种身体上的限制促使了 WhisperPad 的诞生，这是一款“本地优先”的听写应用，旨在通过转录语音并将文本直接注入到当前光标字段中，从而最大限度地减少手部动作。

虽然这款应用解决了关键的个人需求，但它最终撞上了墙：Apple App Store 的审核过程。WhisperPad 被拒绝的故事凸显了严格的平台指南、安全担忧与残障人士的真实需求之间的紧张关系。

冲突点：指南 2.4.5 与无障碍 API

WhisperPad 的核心价值主张是效率。通过使用 accessibility API 来直接将文本注入到其他应用程序中，它消除了用户手动粘贴转录文本的需求。然而，Apple 拒绝了该应用的一个更新，理由是基于指南 2.4.5，声称该应用使用 accessibility API 的方式不符合合法的无障碍用途。

这次拒绝对开发者来说尤为令人震惊，因为该应用的早期版本（执行完全相同的功能）此前曾获得过批准。尽管在申诉中解释了该应用是专门为患有重复性劳损 (RSI) 的用户设计的，但 Apple 仍然坚持其立场。

战略分流：App Store 与直接分发

面对二选一的困境——要么遵守规则并失去应用的核心功能，要么完全退出 App Store——Zelaya 选择了一条第三条路：分流分发模式。

1. App Store 版本（折衷的体验）

为了保持与 Mac App Store 相关的可发现性和信任度，Zelaya 发布了一个合规版本。该版本移除了自动粘贴功能，要求用户必须手动按下 Command-V 来从剪贴板粘贴文本。虽然这使工作流从四个步骤增加到了六个，但它满足了 Apple 的指南，并确保应用可以面向广泛的受众。

2. 直接分发版本（完整的体验）

为了实现最初的愿景，Zelaya 将功能齐全的版本转移到了通过其个人网站进行直接分发。这需要从零开始构建整套基础设施，包括：

• 支付： 实现 Paddle 用于信用卡处理。
• 更新： 利用 Sparkle 框架进行软件更新。
• 授权： 设置许可证密钥服务器。

技术视角与社区辩论

WhisperPad 被拒绝一事引发了开发者之间关于无障碍 API 的本质以及 Apple 对其规则执行情况的更广泛讨论。

安全性论点

一些社区成员认为 Apple 的谨慎是有道理的。accessibility API 的作用范围非常广泛，赋予了应用对系统的重大控制权，包括移动光标和截取屏幕截图的能力。正如一位开发者所言：

"the accessibility API unfortunately is way too broadly scoped... the proper engineering solution would actually be to phase out the accessibility API and replace it with something that is narrowly scoped."

此外还存在固有的“中间人” (MITM) 式攻击风险，应用可能会将恶意文本注入到敏感字段中，例如银行 IBAN。

一致性问题

相反，many 开发者对 Apple 审核过程的不透明性和不一致性表示了沮丧。普遍的观点是，允许行为的“边界”往往是不可见的，且执行起来具有随意性，这让开发者处于一种不确定状态。

"The frustrating part is less that Apple has a boundary here, and more that the boundary seems opaque and inconsistently enforced."

给独立开发者的启示

WhisperPad 的故事为那些试图挑战平台 API 边界的工具开发者提供了几个关键启示：

• 约束即催化剂： 最初看似是障碍，却迫使开发者掌握了自身的构建配置、支付流程和更新流水线，最终创建了一个更稳健的商业结构。
• 多样化分发： App Store 是一个强大的发现工具，但对于需要深度系统集成的应用来说，将其作为唯一的失败点是具有风险的。
• “合规并扩展”策略： 当平台说“不”时，选项很少仅仅是“遵守”或“退出”。构建应用的阶梯式版本——一个用于商店，一个用于直接发布——可以让开发者在维持覆盖范围的同时，保留其产品的核心功能完整性。