watchOS 新特性
What's new in watchOS
2025年6月13日
一句话判断
watchOS 26 把 Apple Watch 的应用分发逻辑从”用户找应用”翻转成了”系统替用户挑应用”——RelevanceKit 才是这场 Session 里真正改变游戏规则的东西。
这场 Session 讲了什么
watchOS 26 做了一件大事:它让 Apple Watch 应用不再需要等用户主动打开。Controls 提供了一键触发的入口,RelevanceKit 告诉系统什么时候该展示你的内容,Smart Stack 负责把它们放到用户眼前。三个能力串起来,形成了一条全新的触达链路。你写的不再是”一个应用”,而是”一组可以在不同上下文中被系统调用的能力”。
arm64 架构迁移是这背后的基础设施升级。Apple Watch 终于告别 32 位,计算天花板被打开了。这意味着之前因为性能被卡住的场景——复杂的图表渲染、实时数据处理、本地 ML 推理——现在可以认真考虑了。MapKit 的完整支持也是受益者之一,路线规划和路线叠加终于能在手腕上跑起来了。
Liquid Glass 设计语言的落地则是一个提醒:你的应用图标和控件样式需要跟着更新,否则在新系统上会显得格格不入。这不是可选项。
值得深挖的点
RelevanceKit:你在跟系统博弈,不是在写代码
RelevanceKit 的表面 API 很简单——实现一个 recommendations() 方法,返回一组 AppIntentRecommendation。但真正重要的不是怎么调用 API,而是理解它背后的博弈逻辑。
系统会综合所有应用的相关性信号来决定 Smart Stack 的排序。你提供的信号越精确、越贴合用户当前上下文,你的小组件就越有可能出现在顶部。但这里有个陷阱:过度推荐会被降权。如果你每次位置变化都触发推荐,系统会认为你在刷存在感,反而把你往后排。这跟 App Store 的 ASO 逻辑很像——苹果永远在打击”试图操纵系统”的行为。
对开发者来说,这意味着你需要换一种思维方式。以前你关心的是”我的 UI 长什么样”,现在你得关心”用户在什么时刻最需要我”。早晨通勤时推荐日程,下班后推荐运动提醒,睡前推荐睡眠追踪——每个推荐都应该有明确的上下文理由。质量永远比数量重要。
旧方案里,Complication 是固定的,用户选了你的 Complication 就一直在那。RelevanceKit 的逻辑完全不同——你的内容是动态出现又消失的,完全取决于系统对你信号质量的判断。这是一种从”用户选择”到”系统推荐”的范式迁移。
Controls:轻量到可以”顺便”实现,但也别太随意
Controls 的设计哲学是”足够轻量,iOS 端实现了就能在 watchOS 上自动继承”。这大幅降低了开发成本——如果你的 iOS 应用已经有 ControlWidget,watchOS 端几乎零代码就能获得支持。听起来很美好,但”自动继承”不等于”自动好用”。
watchOS 的屏幕小、交互距离短、用户注意力只有几秒。一个在 iPhone 上看起来不错的 Control,搬到手表上可能文字被截断、图标辨识度不够、操作反馈不明确。自动继承解决的是”有没有”的问题,解决不了”好不好”的问题。如果你只是让 iOS 端的 Control 原封不动出现在手表上,用户体验大概率是粗糙的。
Controls 的定位是”快速触发”——一键开始运动、快速开灯、即时记账。它不适合承载复杂交互。如果你发现自己在 Control 里塞了太多状态和逻辑,说明你选错了工具。Toggle 类型适合有明确开/关状态的场景,Action 类型适合一次性触发,别搞混了。
代码片段
创建一个 Control 控制项
健身应用希望用户在控制中心一键开始运动。
import WidgetKit
import SwiftUI
struct QuickStartWorkoutControl: ControlWidget {
var body: some ControlWidgetConfiguration {
StaticControlConfiguration(kind: "com.example.startworkout") {
ControlWidgetToggle(
"开始运动",
isOn: isWorkoutActive,
action: StartWorkoutIntent()
) { isActive in
Label(isActive ? "运动中" : "开始运动",
systemImage: isActive ? "figure.run" : "play.circle")
}
}
}
}
坑:kind 标识必须和 iOS 端保持一致,否则自动继承会失效,你会在两个平台上维护两套 Control。
用 RelevanceKit 提供上下文推荐
日程应用希望在早晨自动将今日日程推送到 Smart Stack 顶部。
import WidgetKit
import RelevanceKit
struct SmartReminderProvider: AppIntentTimelineProvider {
func recommendations() -> [AppIntentRecommendation<ConfigurationIntent>] {
let morningIntent = ConfigurationIntent()
morningIntent.period = .morning
return [
AppIntentRecommendation(intent: morningIntent,
description: "早晨日程提醒")
]
}
}
坑:返回太多推荐会被系统降权,宁可少而精,也不要每个时间段都塞一个。
在 watchOS 上显示路线
户外跑步应用在手表上展示完整的跑步路线。
import MapKit
import SwiftUI
struct RouteMapView: View {
@State private var route: MKRoute?
var body: some View {
Map {
if let route {
MapPolyline(route)
.stroke(.blue, lineWidth: 4)
}
}
.task {
let request = MKDirections.Request()
request.source = MKMapItem(placemark: MKPlacemark(coordinate: startCoord))
request.destination = MKMapItem(placemark: MKPlacemark(coordinate: endCoord))
request.transportType = .walking
let directions = MKDirections(request: request)
let response = try? await directions.calculate()
route = response?.routes.first
}
}
}
坑:手表可能只通过蓝牙连 iPhone,网络延迟很高。不做离线缓存和加载状态,用户看到的就是一片空白。
最佳实践
建议优先做三件事。
第一,检查项目里所有 C/ObjC 依赖是否兼容 arm64。这是阻塞项,不解决后面什么都做不了。第三方库需要更新到支持 arm64 的版本,趁现在还有时间,先排查。
第二,为应用最核心的一个高频操作实现 Control。不要试图覆盖所有功能,先挑一个最能代表应用价值的操作——健身应用就做”开始运动”,记账应用就做”快速记一笔”。把 kind 标识跟 iOS 端对齐,一份代码同时覆盖两个平台。
第三,认真思考用户在什么时刻最需要你的应用。不是”什么时候方便展示”,而是”什么时候用户真的会用”。把这个思考转化成 RelevanceKit 的推荐信号。别贪多,一两个精准的推荐比十个模糊的推荐有效得多。
Liquid Glass 的图标更新不要拖。新系统上线后,没更新图标的应用在视觉上会非常突兀,用户第一印象会打折扣。
还有什么值得关注
- Liquid Glass 全面落地:控件、图标和系统空间的视觉风格大改,你的应用如果不更新图标会显得格格不入。
- MapKit on watchOS:完整支持路线查找和路线叠加,运动类应用终于不用自己造地图轮子了。
- Smart Stack 成为一级分发入口:它不再只是”看看小组件”的地方,而是系统主动推送内容的核心界面。