更多內容，歡迎關注公眾號 「Swift花園」 喜歡文章？不如來個 ??➕三連？關注專欄，關注我 ???watchOS 應用
相比 macOS，iOS 和 tvOS ，watchOS (目前為止) 並非是完全獨立的平臺，一定程度上依賴配對的 iPhone 。
watchOS 6.0 之後，watch app 可以獨立釋出和安裝，也就說，應用生態上可以獨立了。但是，某些功能要想發揮最大的效用，還要藉助 iPhone 裝置的計算能力。畢竟，後者目前還是要強大很多。可以這麼理解，當需要用到 watch 本身不具備的硬體能力時，如視訊拍攝，你仍可以把 watch 視為控制器。這個跟人們看待早期智慧手錶的視角一致。
Watch app 和擴充套件
watchOS app 跟 iOS app 最顯著的差異是前者被嚴格的分成了兩部分。第一部分稱為 Watch app —— 有點混淆對吧？正常理解，兩部分加起來才是一個完整的 app 。但字面上，這個主要由 UI 構成的部分就叫 Watch app ，所以我們乾脆以 UI 來代表，第二個部分是 WatchKit 擴充套件。兩部分有各自獨立的資料容器，如果需要共享容器中的檔案，需要用到 App Groups 。
watch OS 6 引入 SwiftUI 後，情況變得有些複雜。因為 SwiftUI 中，UI 即程式碼。原來的 watch app 部分只有一個 hosting view 。
這些年 watchOS 的變化
watchOS 1 中，app UI 執行在 watch 上，但擴充套件執行在 iPhone 上。擴充套件可以很容易地與裝置上的其他 iOS app 通訊，但擴充套件和 watch UI 之間的通訊是裝置間的，因此整個 app 執行很慢。
watchOS 2 中，擴充套件被移到了 watch 上。watch app 和 iOS app 通訊需要藉助 WatchConnectivty framework。因為擴充套件處於 watch 上，所以能用到 SDK 自然變少了。當然，後來各種缺失的 SDK 也被陸續新增到 watchOS 中。
watchOS 4 中，擴充套件和 UI 被合為一個程式執行。當然，這一點對開發者來說相對無感，唯一的效果是 app 執行的更快了。
watch OS 5 以前，WatchKit app 需要依賴 iPhone 的連線來完成大部分通訊。它只能連線 iPhone 連線過的 “已知 Wi-Fi 網路” 。watch OS 5 引入了連線全新 WiFi 網路的能力。
在 watch OS 5 及之前的版本，watch app 總是要求有一個伴生的 iOS app 。watch app 是內建在 iOS app bundle 中，它的安裝也是通過先安裝 iOS app ，再間接下載到 watch 上來完成的。最近的 watch OS 6 ，watch app 真正意義上宣佈獨立。你既可以採用之前的 iOS app + watch app 的方式， 也可以只開發獨立的 watch app 。watch app 不再是內建在 iOS app 中，兩者被分隔在各自平臺的 App Store 釋出。因此，對於因特網的連線方式，最新的建議是 藉助 URLSession ，CloudKit 等直接下載資料到 watch ，只有在真的需要跟 iPhone 交換資料時才用到 WatchConnectivity 。
多於一個使用者介面
iOS app 通常有一個主要的使用者入口。人們想到 iOS app 的時候，通常想到的是主介面上的圖示。當然，也有各種擴充套件可以訪問 app 的不同部分，但是通常被認為是主 app 的附屬。你使用 app 的主要姿勢是開啟主 app 。
來到 watchOS ，情況大不相同。主 UI ，根據你的用例，很有可能不是最常被使用的部分。其主要原因在於 iPhone 和 Apple Watch 完全不同的互動模式。你不可能像在 iPhone 上那樣在 watch 的螢幕上花很長的時間瀏覽內容吧？很顯然，那很不舒服。
對於 watchOS ，Apple 一直重複的關鍵詞是 glances 或者說 glanceable 。期望的 app 互動方式是：抬起手腕，看錶，做一兩個點選（或者甚至都不點選），或者轉一下數字表冠，然後放下手腕，回到現實。這一系列動作的平均時間是以秒計的。實際上，建議是在 2 秒內讓使用者找到目標資訊 (glanceable) 或者執行動作 (actionable) 。
如果你用過 watchOS app ，你應該知道通過主 app 找到目標資訊需要一點技巧。首先，你要在主屏上那一堆六邊形網格中找到 app ，然後點選，等待載入，然後在 app 的不同屏之間尋找你要的東西。基於此，也取決於你的 app 型別，極有可能你的主 UI 只會偶爾被用到。 WatchKit app 實際上提供了一些其他的入口來互動，它們可能更重要。
Notification
通知實際上是 watch 的一個絕佳的應用場景。花不到一秒的時間看一眼手錶，比從口袋裡掏出手機來省事不少吧？許多人會告訴你，他們戴 watch 的主要用途就是看通知。
但是，通知用的好不好，對不對，主要還是取決於你的 app 型別，通知的目的。比如，你的目的是不定期的通知使用者某些事情發生了，通知可以是你的 app 很重要的一部分。典型的，提醒事項 app 。
watchOS 上通知的 UI 有三種變體：
- 只有預製的靜態資訊
- 非互動式的動態資訊
- 可互動的動態資訊，watchOS 5 引入
watch OS 6 允許推送繞過 iPhone ，只到達 Apple Watch 的遠端通知。
Glances / Dock
watchOS 1 開始，引入了一種被叫做 glance 的介面，卡片式，可點選，水平滾動。藉助 storyboard 上單獨的場景構建。
watchOS 3 開始，glance 被廢棄，由 dock 取代，後者是通過按壓表側的長按鈕訪問。它的工作方式和 glance 相似，但是卡片的外觀是基於主 app 的實際 UI (類似 iOS 上的體驗)，通過系統對 app 生命週期某些節點的快照來實現。當你完成滾動，選擇了某個 app 後，系統會喚醒這個 app ，不久之後這個 app 實際的 live 檢視會更新 dock 的靜態圖片。
watch OS 4 之後，dock 變成豎向滾動，跟 iOS 的體驗更相似。
Complications
“Complications“ 是 Apple 給錶盤上的各種 widget 取的一個比較有逼格的名字。
Complications 有很多不同的家族，為不同的錶盤設計 —— 圓形的，矩形的，小的，大的。這些 complictions 的共同點是展示資訊的空間極其有限，一直可見（啟用狀態），因此需要保持最新狀態。
你可以想象，complication 的特點是不可能通過讓 app 持續執行在後臺，並且完全訪問錶盤的方式來實現的。因為這樣做電池撐不住。
Apple 的解決方案是你需要週期性的提前提供一個包含給定時間範圍的 timeline 資料給 complication 用於顯示。系統儲存這份資料，到時間點了自動切換到正確的狀態。你不能在 complication 裡隨意顯示內容 —— 你只能從給定的 complication 家族中選擇預先定義好的模板，然後填充一些精心準備的，允許系統在必要時簡化以便適配可用空間的資料。
這裡面的一個挑戰是：如何找出有用的東西，填充到這麼小的空間裡 —— 同時這也是一個能簡化工作的約束，因為你只有有限的選項。
Apple 一開始就說了，complications 只對部分 app 有意義 —— 因而並非每個 app 都有一些關鍵資訊，可以展示為一個數字或者一行文字。不過，從 watchOS 3 開始，官方建議所有的 app 都實現一個 complication ，即便這個 complication 只是一個靜態的啟動器。（個人認為這個要求對使用者的意義在於，使用者可以在錶盤上新增特定 app 的 complication ，僅僅作為啟動器也是有價值的）。技術層面，系統可以針對當前表格的啟動器，做一些優化，以便 app 啟動更快。
Siri
最後一個入口就是 Siri 了， watchOS 5 以後，Siri 可以用於更多的用例，例如發訊息，todo list 等等。
我的公眾號這裡有Swift及計算機程式設計的相關文章，以及優秀國外文章翻譯，歡迎關注～
