2026 年 4 月，独立开发者 Rene Zelaya 的 Mac 菜单栏听写应用 WhisperPad 在提交 1.5 付费更新时被苹果拒绝。理由是 App Store Guideline 2.4.5：苹果认为该应用使用 macOS Accessibility API 向其他应用注入文本，并不属于被允许的无障碍用途。

这件事的重要性不在于“苹果封杀无障碍应用”——事实也不是这样。真正的争议是，当一个应用为了减少键盘操作而跨应用自动输入文本时，它到底是在帮助受限用户，还是越过了平台安全边界。WhisperPad 最终被拆成两个版本：App Store 版只把转写结果放进剪贴板，用户再按 Command-V；站外完整版保留自动粘贴。

WhisperPad 解决的不是转写，而是少按几次键

WhisperPad 的起点很个人。Zelaya 在 2024 年秋天开始出现手指关节疼痛，到 2025 年初已无法长时间打字。他先试过苹果内置听写，但识别错误后的修改仍要靠键盘完成，省下的动作又被纠错吃掉。

WhisperPad 的设计很直接：常驻菜单栏，按快捷键开始说话，在 Mac 本地完成语音转写，不把音频上传到服务器，然后把文本放进当前光标所在位置。如果用户切走窗口，文本会进入剪贴板。

这里有一个普通读者容易忽略的限制：对手部损伤用户来说，“多按一次 Command-V”不是小细节。应用原本的目标不是把语音变文字，而是把从想法到输入框之间的手部动作降到最低。

版本文本进入方式用户动作判断
早期 App Store 版自动注入当前应用授权 Accessibility 后直接输入曾以相同权限和功能通过审核
1.5 付费更新继续自动注入提交后被拒苹果认为用途不合规
现 App Store 版放入剪贴板用户手动 Command-V合规但体验打折
站外完整版自动粘贴保留原流程功能完整但分发门槛更高

苹果的拒审核心，是跨应用控制权

Accessibility API 在 macOS 上并不罕见。很多效率工具、窗口管理器、自动化软件都会请求这项权限，因为它能读取界面元素、模拟操作或辅助用户控制其他应用。问题也在这里：一旦允许应用“替用户操作其他应用”，它就可能触及输入劫持、误操作、隐私和安全风险。

苹果没有说 WhisperPad 是恶意软件。Zelaya 也承认，平台规则有安全理由。他的分歧在于：这款应用因为真实手部损伤而诞生，功能目标也是减少输入负担，却被判定不属于合规的无障碍使用。

横向看，Mac 生态长期允许站外分发，这与 iPhone 上更封闭的分发模式不同。TextExpander、Keyboard Maestro、BetterTouchTool 这类工具之所以能存在，很大程度上依赖 macOS 给高级用户和自动化工具留下的空间。WhisperPad 的尴尬在于，它既像无障碍软件，也像跨应用自动化工具；而 App Store 审核往往更倾向按权限风险而不是用户动机来裁剪边界。

早期版本曾以同样权限和功能过审，也让这次拒绝更难解释。Zelaya 申诉后，苹果在 4 月 21 日表示会进一步查看，并要求他不要在线程中回复；约一个月后，他在 5 月 21 日询问进度，随后收到的仍是拒绝。

双版本并行，是独立开发者的现实选择

Zelaya 没有退出 App Store。他选择把产品拆成两个构建目标：App Store 版保留发现渠道和基础体验；站外版通过 Paddle 收款、Sparkle 更新、许可证服务器验证，提供完整自动粘贴功能。他在 5 月 27 日完成站外发布流程。

这对独立 Mac 开发者有现实参考价值。App Store 带来搜索、支付和信任背书，但审核不确定性会把某些边缘功能压缩掉；站外分发自由度更高，却要自己处理支付、更新、授权和用户信任。对一个小团队或个人开发者来说，这不是理念选择，而是维护成本选择。

受影响最直接的是两类人：一类是有重复性劳损、肌腱炎或其他手部限制的用户，他们可能愿意为了少一次按键安装站外版；另一类是做自动化、辅助输入、窗口控制的 Mac 开发者，他们要重新评估 Accessibility API 在 App Store 内的可接受边界。

接下来最该观察的不是 WhisperPad 下载多少，而是苹果是否给出更清晰的审核解释：什么情况下跨应用输入属于无障碍辅助，什么情况下属于被禁止的自动化控制。没有这条线，开发者只能用反复提交和被拒来摸边界，成本最后会转嫁给真正需要这些工具的人。