苹果Walkie-Talkie被砍，他决定自己为妻子重建一个

苹果在 watchOS 27 中移除了陪伴用户多年的 Walkie-Talkie 对讲机功能，一位软件工程师因此决定亲手为妻子重建一个以 Apple Watch 为核心的替代应用，并全程公开记录开发过程。

消失的黄色按钮

对这位开发者来说，Apple Watch 上最常用的应用从来不是健身追踪器或花哨的表盘，而是那个简单的 Walkie-Talkie。它的交互极其克制：点一个联系人，按住大大的黄色按钮，说话。对方的手腕上就会传出你的声音，不用打字、不用掏手机、不用等回复。

他和妻子多年来就靠这个功能沟通。升级到 iOS 27 和 watchOS 27 后，他照例第一时间更新了手表。几天后妻子试着呼叫他，没反应——起初他以为是连接不稳或偶发 bug。第二天他自己尝试呼叫妻子时，才发现这个应用已经彻底消失了。

查阅官网更新日志后确认，Walkie-Talkie 已不再被支持并正式移除。没有预告，没有替代方案。

watchOS 27 的移除并非孤立事件。苹果通常会在系统更新日志中以“不再支持”的措辞批量清理低使用率或维护成本高的旧功能，而 Walkie-Talkie 自 2018 年随 watchOS 5 推出后，长期依赖 iPhone 端的 FaceTime 音频通道与专门的 PTT 后台权限。一旦底层框架策略调整或安全模型收紧，这类依赖私有链路的轻量应用很容易被整体砍掉。更麻烦的是，用户端的应用图标会直接消失，而不会像停用服务那样弹出通知，因此升级后往往要等到某次呼叫失败才会察觉。

为什么一个小功能如此重要

Walkie-Talkie 从来不是用来长聊的。它处理的是那些不值得打电话、但在手表上打字又很烦的碎片消息："在路上了"、"要不要喝咖啡"、"饭好了"。

一条来自手腕的语音短消息恰好卡在中间地带——比文字更有温度，两秒钟就能说完，而且能听到对方的声音。这类需求看似微小，却高频到足以影响日常体验。当它消失后，夫妻俩的沟通方式明显变得不一样了。

开发者说，这种"丢了之后才意识到有多需要"的感觉，通常说明一件事值得被重新造出来。

他要造什么

思路很直接：一个把 Apple Watch 放在第一位的对讲机应用。iPhone 可以用，但手表才是主角。

他把设想描述为"苹果 Walkie-Talkie 和 Zello 之间的某个东西"。第一版的交互流程是：打开应用，选一个联系人，点击 Connect。对方的手表会震动——即使应用没打开——弹出请求让他确认。接受后即建立连接，按住说话，松开收听。如果对方没接，显示"Not available"，结束。

语音留言（对方忙时使用）、群组通话等功能留到后续版本。他的判断是：宁可先发布一个自己和妻子每天都会用的小东西，也不要做一个永远完不成的大家伙。

平台限制才是真正的设计者

这不是一个周末项目。开发者有原生设备工具链的经验，很清楚这一点。

Apple Watch 为省电做了严格限制：手表应用不能长时间驻留后台等待通话，不能随意保持长连接。更关键的是，苹果自家的 push-to-talk 工具包只存在于 iPhone 上，手表端没有。

那怎么唤醒对方的手表并立刻开始说话？他的方案是借用电话的机制——点 Connect 后，对方手表收到一个特殊通知来唤醒应用，会话以类似通话的方式运行，从而在熄屏状态下保持存活状态。

代价是来电界面看起来会像一通电话。不理想，但他认为在平台规则内做设计，好过跟规则对抗。这些限制对产品形态的影响，比任何功能清单都大。

Push-to-Talk（PTT）框架是苹果在 iOS 端提供的专用 API，允许 VoIP 类应用在后台保持待命状态，并在收到对讲请求时唤起接收方的设备，从而实现“按住即说、松开即听”的低延迟体验。它依赖系统的 VoIP 通话通道与音频会话管理，因此对后台唤醒、麦克风占用和音频优先级有特殊权限。关键限制在于：该框架只随 iOS 提供，watchOS 并未暴露对应 API。这意味着手表端应用无法直接复用 iPhone 上的对讲机机制，开发者只能绕道使用通知唤醒或借助通话类接口模拟，这也是文中“借用电话机制”的根本原因。

公开构建，也公开失败

开发者计划把每一步都写出来：技术决策、踩过的坑、运行成本、学到的东西。他坦言第一次往往失败多于成功。

公开的动力有两个。一是问责——说出来了就得做完。二是他在网上几乎找不到从零构建一个真实 Apple Watch 应用的完整记录，也许这些内容能帮到其他人。

目前这个应用还没有名字，他正在向读者征集建议，也想听听曾经用过 Walkie-Talkie 的人最怀念它的哪一点。下一篇他会定名、在 App Store 占位、搭好项目骨架。一个只为两个人做的对讲机，能不能一路走到上架，他会继续记录。

背景补充

watchOS 的后台执行模型值得单独说明。与 iPhone 不同，手表应用无法长时间驻留后台保持网络连接，系统会在数秒内挂起绝大多数进程以节省电量。开发者可用的长期运行场景非常有限，主要围绕音频播放、定位跟踪、锻炼会话和通话类活动。要让对讲机在手腕上“随时可被叫醒”，就必须借助系统级通道，例如推送通知、CallKit 通话界面或音频会话中断，才能把应用从挂起状态拉回前台。这也解释了为什么文中的方案看起来“像接了一通电话”——它本质上是在借用系统赋予通话的存活权限，来换取对讲所需的实时性。