Dev Team 開發流程全公開：我們如何開發 Hikingbook for Apple Watch

Published in

Hikingbook Blog

17 min readMay 10, 2024

Hi，我是 Hikingbook iOS developer Riley。

Hikingbook iOS app 在今年邁入了第五週年，而在 2023 年，我們決定開發 Hikingbook for Apple Watch，讓使用者能在 Apple Watch 上更便利的使用 Hikingbook app。在 watchOS app 的開發過程中，我們嘗試了與以往不同的開發模式，希望 watchOS app 一上線，就能帶給使用者良好的產品體驗，讓 watchOS app 無縫整合進 Hikingbook 的產品體系中。

在這篇文章中，我們將會分享 Hikingbook Dev Team 是如何打造 Hikingbook watchOS app，揭開從 0 到 1 完成 watchOS app 的開發流程，並分享在開發 watchOS app 的過程中遇到了哪些挑戰。

開發流程

Hikingbook Dev Team 在 iOS app 既有的開發流程為：

Spec Review：在 Spec Review 中，開發和行銷團隊的成員們共同參與討論，了解本次開發的功能主要目標為何。透過 Spec Review ，團隊成員會知道功能的開發「希望解決什麼樣的問題」、「要達成的目標是什麼」，以及「影響的使用者是誰」，並通過會議中的討論確認可行性，達成最後對該 Spec 的共識。
Design Review：Spec Review 結束後，會由產品設計師進行設計，在設計完成後進入 Design Review 的環節，和團隊說明設計的概念、最終呈現的樣貌以及使用者操作的 flow 會如何進行。在過程中，開發者也會針對設計在實作上的可行性提出建議，大家會一起思考使用者操作的流程是否順暢並提供反饋，會後產品設計師也會根據大家的共識進行調整。
Dev Implement：完成 Design Review 後，就會正式進入開發階段（Dev Implement），此時工程師們會根據已經確定的 Spec 內容，以及 Design 的最終版本進行開發。若工程師在開發的過程有發現問題，會再發起討論和相關人士確認如何調整，待所有功能開發完成後，最終交付開發完成的 app。
Internal Test：App 功能開發完成後，會進入測試階段（Internal Test)，由 Hikingbook 成員測試開發完成的 app 是否符合 Spec 和 Design 的設計。若在測試的過程中發現問題，會再由開發者進行調整，待完全通過測試後，才會進入下個階段。
Release：待所有功能通過測試後，就會正式 release，進行 app 的送審，並上架至 App Store 供使用者下載與更新。

開發流程 For Apple Watch

在這次 Hikingbook for Apple Watch 的開發中，我們針對原本的開發流程進行了一些調整。由於開發團隊成員過往都沒有開發 watchOS app 的經驗，而 watchOS app 與 iOS app 在 App Life Cycle、 UI 介面的呈現、使用的 API、使用者習慣操作的 flow 等面向上都有所不同，開發團隊需要較多的時間來摸索並熟悉 watchOS 的開發。

此外，由於 Hikingbook iOS app 已經是一個相當成熟的產品，我們希望 watchOS app 上線後，也是一個具有高穩定度的產品，讓使用者的使用體驗能達到相同的水準。

考量以上兩點，我們在開發流程上做了新的調整，讓本次的 watchOS app 開發流程如下：

我們在開發的過程中增加了 POC（Proof Of Concept）階段，在實際開發前先進行 watchOS 技術上的研究。此外，除了原先的內部測試（Internal Test）外，也增加了 Beta Test 作為外部測試，邀請有 Apple Watch 的使用者在產品正式上線前，就可以搶先體驗 watchOS app ，並提供意見反饋，供開發團隊參考與調整。

以下我們將更詳細的分享 watchOS app 的 POC、Develop Implement、Beta Test 這三個階段在開發過程中是如何進行的。

POC

在 POC 的階段，最主要的目標是確認 Hikingbook app 的核心功能在 Apple Watch 上實現的可能性。 Hikingbook app 的使用者在戶外活動時可以紀錄活動的軌跡，並可透過 Dashboard 查看活動中所累積的數據，對使用者而言這是在進行戶外活動時最重要的核心功能，因此，在 POC 階段我們優先嘗試相關功能實作的可行性。

另外，Apple Watch 比起 iPhone 可以提供更多的生理數據，也提供了 Workout Sessions 可以更精確的追蹤使用者在 Apple Watch 上進行活動的數據。我們也希望整合這些 Apple Watch 所能提供的資料進入 Hikingbook watchOS app 中。

綜合以上的考量，我們在 POC 階段我們主要針對以下幾點進行研究：

iOS app 和 watchOS app 之間的溝通及資料傳輸方式
watchOS app 的 Life cycle
透過 watchOS 操作 iOS app 的關鍵行為
透過 watchOS 蒐集 CLLocation 資料
了解 watchOS workout sessions 的運作方式
透過 watchOS 取得 HealthKit 所提供的生理資訊
確認 watchOS 是否可呈現地圖

在這個階段，我們對於 watchOS app 實際上會包含的功能尚未有明確的定論，關於 watchOS app 是可獨立 Hikingbook iOS app 下載、運作，擁有完全獨立於 iOS app 功能的 Independent watchOS app ，或是必須要依賴 iOS app 才能操作使用的 Dependent watchOS app 這點也尚未決定。

因此在 POC 主要是作為技術可行性的探究，並讓開發者能有時間認識 watchOS，在過程中，不需要開發完整的功能或是建立實際要在 app 中使用的 foundation，而是一個快速嘗試的過程，讓後續在討論 watchOS 的功能時，開發者能迅速的評估技術限制，並加速後續實際開發時所需的時間。POC 的範圍也不只限於這次 watchOS app Spec 的開發，而是希望更了解 watchOS 的技術，了解未來拓展功能的可能。

了解更多 Dependent watchOS app 和 Independent watchOS app 的差異：https://developer.apple.com/documentation/watchos-apps/creating-independent-watchos-apps/

在 POC 階段，我們也發現了幾個後續開發時可能會面對的潛在挑戰，並也因此可以先為未來實際開發做準備。

以 SwiftUI 進行開發

iOS app 的 UI ，大部分開發者熟悉的是以 UIKit 進行開發，在近年來 SwiftUI 的技術逐漸成熟，使用 SwiftUI 開發的比例也有所上升。而在 watchOS 中，對應 UIKit 的開發方式為 WatchKit，其中包含了 Storyboard 可供開發者使用。

然而，這幾年 Apple 強烈建議開發者以 SwiftUI 進行 watchOS app 的開發，在 WatchKit 的文件中，明確的提到：

Building your app with SwiftUI gives you more control over the user interface than designing it in a storyboard. When creating a new watchOS app, strongly consider using SwiftUI.

在 watchOS 7 釋出後，WatchKit storyboards 已遭 deprecated，必須使用 SwiftUI 進行開發，在 Xcode 14 開始，已不支援建立 WatchKit storyboard。

由此可知，現在要進行 watchOS app 的開發，開發者無可避免的必須面對 SwiftUI。若對 SwiftUI 不夠熟悉，在開發上可能會需要花費更多時間摸索。而幸運的是在 Hikingbook iOS app 中，我們已經以 SwiftUI 進行開發一段時間，因此在 watchOS 開發的過程中，可以較無痛地銜接。

watchOS app 與 iOS app 的狀態

雖然在 POC 階段我們尚未確定 watchOS app 是否為 Dependent watchOS app，但我們也希望對 watchOS app 與 iOS app 之間的關係有初步的了解。透過研究 Watch Connectivity 所提供的 API，我們發現可以透過以下幾個 API 了解對應 app 的狀態：

isPaired：可知道 iPhone 是否有已配對的 Apple Watch
isWatchAppInstalled ：可確認 watchOS app 是否已安裝
isReachable ：可判斷對應的 app 是否處在可以接收訊息的狀態

透過對這些 API 的研究，讓我們更了解在跨裝置 app 溝通時可能遇到的問題，以及技術上的限制，如 isReachable 只能判斷對應的 app 是否可以接收訊息，但無法直接透過這個 property 知道對應的 app 是在前景還是背景。後續我們也能更完整的思考跨裝置 app 之間溝通的 flow 該如何設計，並可以提早和產品設計師討論是否需要有引導使用者操作的相關畫面。

App 間的資料傳輸

watchOS 與 iOS 間的資料傳遞，若是在沒有網路的情況下，主要需要透過 WatchConnectivity 的 Framework 進行，它提供了不同的 API 供不同情境的傳輸使用：

在這之中需要注意的是，並不是所有的 API 都支援在模擬器上使用， transferUserInfo(_:) 在文件中有特別註明需在實機上使用，而 updateApplicationContext(_:) 雖未在文件中明確指出，但在 POC 的過程中，我們卻也遇到無法在模擬器上操作的情況，在 Apple Developer Forums 也可看到相關討論。

透過 POC 讓我們預先知道對於 watchOS app 和 iOS app 之間資料的傳遞，在開發的過程中會更需要仰賴在實機上運行及測試，以避免模擬器無法正確運行的情況。

在 WatchConnectivity 的實作中，我們也注意到了在資料傳輸格式上的限制，在傳遞 [String: Any]的資料時， Any並非什麼型態的資料都能傳送，而必須是 primitive types 的資料，如：String、Int、Double、Array、Data 等，因此在資料的傳遞上，可能會需將資料進行轉型處理。此外，【iOS -> watchOS】與 【watchOS -> iOS】的雙向溝通，會因 app 是否已開啟、app 在前景/背景、watchOS app 是否處於 workout session 等因素而影響到資料的傳輸。

watchOS 的生命週期也與 iOS app 不同，不會長時間處於 active 狀態，使用者不需特別將 app 退到背景，而是將手腕放下就會使 app 進入 inactive 的狀態，這對於資料傳輸時所要選用的方法也會有所影響。

另外，在 2023 年 6 月的 WWDC 中，Apple 宣布在 watchOS 10 推出新的 Workout Mirroring API，根據 Build a multi-device workout app 的介紹，我們注意到這個新的 API 對於 app 之間資料的傳輸可以更加即時，也更符合我們對於 app 之間互動的需求。但需要考量的是在只有 watchOS 10 可以使用的情況下，對於後續是否要以此 API 作為整個 app 傳輸的基礎，有更多需要考量的面向。

watchOS app 安裝

在 POC 的過程中，我們嘗試了將 watchOS app 裝入 Apple watch 裝置中以觀察功能的運行，而在這個過程中，我們注意到要將與 iOS companion 的 watchOS app 裝進 Apple Watch 中，需要透過 iOS app 進行安裝，不像一般透過 Xcode 即可將 app 直接安裝進 iPhone 中。

而在多次的安裝過程中我們也發現安裝 watchOS app 時，較容易遇到各種問題導致安裝不順利，除了基本的 watchOS app 需開啟開發者模式外，iPhone、 Apple Watch 及 Xcode 需重新啟動讓 watchOS app 順利安裝也是時常會遇到的情況。雖然不是什麼大問題，但在開發的過程中無疑會影響到開發的速度，再加上上述在 Apple Watch 的模擬器中有些 API 無法正常運作，如何取得在實機及模擬器上的開發取得平衡也是後續開發過程需要考量的。

在 POC 的最後，我們將實作 Hikingbook iOS app 核心功能的結果以 Dependent watchOS app 的方式安裝進 iPhone 及配對的 Apple Watch 之中，並在 Hikingbook 團隊中示範如何做到 iOS app 及 watchOS app 中同步紀錄活動。透過這個分享，讓團隊更能想像 Hikingbook for Apple Watch 的完成的樣貌。

Dev Implement

Foundation 建立

在團隊完成使用者訪談並收斂 watchOS 的核心功能，並經歷 Spec Review 和 Design Review 後，確立了 Hikingbook watchOS app 會以 Dependent watchOS app 的樣貌登場，並會負載紀錄及查看活動數據的核心功能。緊接著也正式進入了 watchOS app 從 0 到 1 的開發階段。

首先最重要的是建立 watchOS 和 iOS app 之間傳遞資訊的 Foundation，如同網路層在 iOS app 中的重要性，由於 Hikingbook watchOS app 的資料來源主要來自於 iOS app 所傳遞，因此，我們以 Watch Connectivity 建立兩者的傳輸，為了讓所需的所有資料可以順利傳遞，讓使用者在 app 於前景時可以即時看到所有數據，並建立完整的 Error Handle，在資料無法正確傳輸時讓使用者還是有良好的體驗，我們花費了許多功夫。由於使用者可同時操作 iOS app 及 watchOS app，若太頻繁的傳輸資料，會造成裝置耗電嚴重，但若傳輸不夠即時，則會發生使用者在兩邊的 app 可能會看到不一致的資料而感到疑惑的情況，因此如何掌握兩者平衡也相當重要。

在開發的過程中，為了克服部分 API 無法在模擬器上使用的問題，我們使用了 command-line arguments 和 arguments passed on launch，指定在模擬器上運行時是用特定的方式進行傳輸，以加速開發的速度，避免部分 API 無法使用導致運行結果不如預期。另外，由於 app 間資料的傳遞頻繁，發生問題時要找到是哪一段資料傳輸發生問題較耗時，我們也善用 Log 打印 watchOS 及 iOS app 之間的傳輸情況，讓 debug 可以更加容易。

watchOS 版本問題

在實際開發的過程中，我們也遇到了 POC 時沒有注意到的問題，那就是在實際開發階段，我們以 watchOS 10 為主進行開發，在前期忽略了 watchOS 8 在 TabView 的行為和 watchOS 9, 10 的差異。雖然在 compile 時不會發生錯誤，但實際運行時，若在 watchOS 8 將一個 .carousel 的 TabView 放進 .page 的 TabView 中，無法讓 View 可以進行上下和左右切換的操作，而造成 watchOS 8 無法採用原先的設計相同的 UI 介面。在發現問題後，團隊開發者和設計師緊急討論，為了在 watchOS 8 上有更良好的體驗，重新打造了不同的介面來呈現數據。

在注意到了不同 watchOS 版本可能發生的問題後，在後續的開發，我們會以 不同 watchOS 版本搭配不同錶面大小的 Apple Watch 的模擬器及實機進行開發與測試，希望能確保在各版本及不同型號的 Apple Watch 的使用者都能有良好的體驗。

開發與測試並行

在開發的過程中，我們也將功能進行更細緻的切分，在整體 app 架構完成後，會在個別功能開發完成後，進入內部測試環節，而非等所有功能都完整開發才一次測試。透過這樣的方式可以讓開發步調更快速，當內部測試發現問題時，可以及時修正，在下一個版本再次測試。經歷了多次的內部測試及修正，仰賴不同部門緊密的協作，最後才能順利的完成 watchOS app 的開發。

Beta Test

在完成內部測試後，我們進入了 Hikingbook 史上第一次的對外 Beta 測試，透過行銷團隊招募有 Apple Watch 的使用者搶先體驗 Hikingbook WatchOS app。

在 Beta 測試的階段，我們希望透過使用者的回饋更了解使用者需求，以及避免 app 不夠穩定的問題。

Beta Test 參與的使用者人數高達 600 多人，提供我們更多元且真實環境下的操作經驗，透過使用者們實際在戶外活動的過程使用 Hikingbook watchOS app，讓我們更能掌握產品的穩定性，並透過他們真實使用後的回饋，讓我們能發現在內部測試中較難發現的問題。

在使用者的反饋中，許多使用者向我們反映了 watchOS app 耗電過快的問題，由於回饋的使用者人數較多，讓我們清楚的了解這並非單一裝置可能的偏誤，而是廣泛影響使用者體驗待解決的問題。而後開發團隊也根據這點進行優化，我們重新調整了資料傳輸的時機、傳輸的頻率，避免在不必要的時候進行資料傳輸，並發現 UI 上的動畫效果不間斷的更新也會造成耗電，因此也關閉了不必要的更新。透過這些調整，在 App 正式上線前，也成功地克服了耗電問題，讓正式上線 Hikingbook watchOS app 能帶給使用者更良好的操作體驗。

正式上線

在 2024 年 1 月 Hikingbook watchOS app 正式上線了 🎉

這次 watchOS app 的開發經驗對我們來說相當寶貴，除了仰賴團隊內外部緊密的協作，成功打造出 Hikingbook 第一個在穿戴裝置上的產品，也有參與 Beta Test 的使用者們的加入，讓產品能更完善。透過使用者們的回饋，也讓開發團隊感到與使用者們更靠近。

POC 和 Beta Test 這兩個階段乍看之下好像拉長了整體開發的時間，但整體而言，我們認為是相當值得的投資。透過 POC 降低了後續開發的風險，避免因為對技術的不熟悉而造成後續可能需要砍掉重練，付出更大成本的可能。POC 也讓開發團隊更快地掌握技術，在跨團隊的討論中，可以更快的回覆問題，並評估技術上的可行性。Beta Test 則讓我們在產品正式上線前增加了不少信心，了解使用者在真實戶外活動中使用的經驗，讓我們能有機會了解在一般內部測試以外可能遇到的問題，並能在正式上線前克服。此外，也提供了除了在 App Store 留下評價外，使用者可以更直接向開發團隊提供回饋的機會。

希望透過這篇 watchOS 開發的分享，讓大家更了解開發團隊在 watchOS app 傾注的心血。若你是開發者，對於開發 watchOS app 有興趣，或是你所屬的團隊有以開發 watchOS app 為目標，希望這篇文章能對你有所幫助！

⌚️ 歡迎你一起體驗 Hikingbook for Apple Watch 的完整功能！

📣 想知道 Hikingbook 產品設計師是如何設計 Hikingbook watchOS app，也歡迎前往如何從 0 到 1 ：設計 Hikingbook 的第一款穿戴式裝置的 App 了解更多！