问题很小，也仍然是完整的产品问题
很多外设应用试图做成一整套生态。对于只需要电量、连接状态和几个可靠按键映射的用户来说，这种体量往往不成比例。Whisker 从相反的问题开始：一个原生工具最少需要哪些能力，才能既轻量又完整？
界面反而是容易的部分
可见界面被刻意保持简单，但不同设备的行为并不统一。蓝牙、USB 与接收器连接暴露的信息不同；Logitech 设备需要专门处理；侧键事件既要被捕获和重写，又不能形成循环或破坏普通点击。辅助功能权限也必须解释清楚，因为应用不能绕过 macOS 的安全边界。
这正是原生开发发挥价值的地方。SwiftUI 让我能够快速迭代产品表面，而 HID 发现与 Event Tap 负责需要直接接入系统的部分。
配置方案把功能变成工作流
一次性的按键映射页面只在当下有用，保存下来的配置方案才能每天使用。工作与游戏场景可以保留不同分配，状态栏入口也比反复打开完整设置窗口更高效。配置持久化、设备切换和多设备状态，因此从“细节”变成了核心行为。
发布会改变“完成”的定义
应用能在开发机运行，并不代表它已经完成。它还需要图标、本地化文案、权限引导、可安装构建、发布说明，以及让用户反馈未支持设备的入口。以 MIT 协议公开 Whisker，也要求仓库和文档能够被我之外的人理解。
项目最终迭代到 1.1.5，共发布 7 个 Release。比版本号更重要的是，它让我从一开始就把分发、兼容性和支持视为产品设计的一部分。
仓库核查揭示了什么
当前提交的 Xcode 工程仍能通过无签名构建，因此已发布代码路径并不只是 README 中的声明。维护风险主要在可复现性：仓库没有 XCTest 目标，发布归档和用户态 Xcode 数据仍被跟踪，工程生成文件还会包含当前 Xcode 工程排除的重复声明。如果今天重新生成工程，反而可能破坏目前可以成功的构建。下一版应该确定唯一权威的工程定义，并把二进制产物移出源码版本控制。