Apple Developer onepage/WWDC26
#WWDC26#watchOS#GroupLab2026-06-11 · 60 分鐘

watchOS Group Lab：把 腕上限制 變成產品判斷

這場 Q&A 把 watchOS 27 新能力放回 Apple Watch 的老問題：小螢幕、短互動、嚴格 background runtime、有限網路與電池。導入 Foundation Models、widgets、Live Activities 或 Workout Zones 時，重點是選對系統入口與 fallback。

// 一句話結論

watchOS 27 的新能力很吸引人，但真正的設計核心仍是 glanceability、personal context、network-aware fallback，以及不要把 iPhone app 的假設原封不動搬到手錶。

Apple Developer · WWDC26 · Video ID: DlVu0yBOphwYouTube 來源
Content map

這場 Lab 在拆四個 watchOS 導入決策

AI

Foundation Models on watchOS 走網路，不跑本機模型

Apple 工程師說 watchOS 上不會使用連接 iPhone 的 on-device model；會透過網路呼叫 PCC 或符合 LanguageModel protocol 的 provider。

入口

不一定要先做完整 watch app

Live Activities、notifications、controls 與 widgets 能先把 iPhone app 的關鍵狀態帶到手錶，適合驗證 wrist presence。

資料

Health 與 Workout Zones 是 watch 的原生優勢

手錶有更貼近當下的心率、卡路里、workout zones、time in zone 等資料，適合做個人化與運動後洞察。

系統空間

Widgets 要看位置與使用頻率決定更新期待

watch face 上的 widget 會被更常看見，更新預期更高；Smart Stack 則取決於使用者實際打開與 relevance signals。

Adoption path

從 iOS app 走向 watchOS 的低風險路線

1

先找 wrist-sized moment

不是縮小 iPhone UI，而是找使用者抬腕 3 秒內需要知道或完成的狀態。

2

用 Live Activities / controls / widgets 試水溫

若只是狀態追蹤、快速 action 或可預測資料，先用系統入口比完整 watch app 更輕。

3

需要 AI 時先設計 availability check

Foundation Models 需要網路、quota、entitlement 與 latency fallback；不要把 AI response 當成一定會立即可用。

4

把資料 freshness 映射到正確 API

可預測用 timeline，事件型用 relevance，短期高頻 session 用 Live Activities，server-driven 用 APNS 或 watch connectivity refresh。

5

首次啟動要能離線或半離線

獨立 watch app 的 heavy asset fetching 不該讓使用者只看到 spinner；先 bundle 最小可用內容，再背景補足。

重點 1：Foundation Models 的 watchOS 版本要把 latency 設計進體驗

Lab 一開始就回答了核心問題：watchOS 上的 Foundation Models 不依賴連接 iPhone 的 on-device model，也不在手錶本機跑模型。它會透過 cellular 或 Wi-Fi 發出 network call，可用 PCC，也可用 Claude、Gemini 等未來 provider 或自訂 LanguageModel conformer。

這代表 watch app 的 AI 功能應該先檢查 availability、quota、entitlement 與網路狀態。適合的 use case 是摘要、濃縮文字、把密集資訊變得可掃讀，而不是把每次抬腕都綁到長時間模型回應。

PCC 需要 entitlement如果使用 Private Cloud Compute 路徑，產品與 release checklist 要納入 entitlement 與不可用 fallback。
Server model 也走同一類抽象符合 LanguageModel protocol 的 provider 可以接上，但仍要處理 token、quota、錯誤與延遲。
手錶適合摘要，不適合塞滿回答開發者可以把長文字變短、把資料變 insight，讓內容符合小螢幕與短互動。
健康資料需要更高產品責任使用心率、workout 或個人洞察時，要把隱私、解釋性與過度推論風險一起設計。

重點 2：watchOS presence 可以從系統空間開始

團隊強調，開發者不必第一步就做完整 watch app。iPhone app 的 Live Activities 會出現在 watch Smart Stack；controls 也能被系統帶進 watchOS Control Center。對很多 app 來說，這些入口已經足以讓關鍵資訊出現在手腕上。

Widgets 與 Live Activities 的差異也很重要。Timeline widget 適合天氣、行事曆這類可預測更新；Live Activities 適合 ride share、運動賽事、session 這類有開始與結束的高頻狀態；controls 則適合立即 action。

重點 3：watchOS 27 的 hidden gems 是小但關鍵的原生能力

除了 Foundation Models、Vision framework、Core AI framework 與 Liquid Glass，Lab 也點到幾個更實務的 watchOS 27 更新：Workout Zones API、SwiftUI reorderable API、watch connectivity based widget updates，以及針對 watchOS 調整過的 Liquid Glass。

Workout Zones 特別值得注意，因為它不只給 zone boundary，還能支援 time in zone 這類運動後分析。SwiftUI 的 reorderable 則是首次讓開發者能在 watchOS collection 中更容易做拖曳排序，Apple 自己也用它實作 Control Center。

風險與遷移注意事項

Background runtime 比 iOS 更嚴格CloudKit sync、asset fetching 與 heavy async work 要考慮 watchdog、battery 與較低 core count。
Widget freshness 不是固定 SLA活躍 watch face widget 可能較常更新；Smart Stack 或較少觀看的 widget 要用 relevance 與 timeline 合理設計。
Liquid Glass 沒有 watch 專屬調整 slider團隊表示 watchOS 以深色 UI、小螢幕與 legibility 平衡；仍可依賴 reduce transparency / increase contrast。
首次啟動不能假設網路可用獨立 watch app 可能在無連線處第一次啟動；要 bundle 最小內容並設計有用的 offline state。

來源

主要來源為 Apple Developer YouTube RSS metadata、YouTube 影片與英文自動字幕。Group Lab 目前未找到 Apple Developer 影片頁 transcript，因此本頁以 Q&A 字幕內容整理，不臆測字幕以外的 demo。YouTube：WWDC26: watchOS Group Lab | Apple。

// TL;DR