Apple平台矩陣：哪些目標平台值得擁有哪種App

Apple推出六個消費級運算平台，開發者可以用單一Swift程式碼庫同時鎖定：iPhone、iPad、Mac、Watch、Vision與TV。SwiftUI搭配iOS 26工具鏈，讓在Xcode中加入任一平台變成勾選方塊的操作。然而這個勾選方塊正是陷阱所在。每多一個目標平台都是一份義務，而非一項功能：每個目標都會擴大設計、測試、無障礙、執行階段模型與後續維護的範圍。一款App的正確目標平台數量，往往少於框架所允許的數量。

此叢集中的App採用不同的組合。Return推出於六個平台（iPhone、iPad、Mac、Watch、Vision、TV）。Get Bananas推出於四個平台（iPhone、iPad、Mac、Watch）。Reps與Water尚未發布，編譯了多個目標平台，但這些App會在上架前縮減範圍。Ace Citizenship與Tappy Color則各自僅推出於iPhone。同一位開發者、同一套工具鏈，卻有六種不同的平台決策。這些決策遵循一定規則；而這些規則值得有一張共通的地圖。

每個平台都必須透過自身真正帶來的特定使用者價值來爭取納入，而不是因為「它能編譯」。能在上架後存活下來的矩陣，是每個目標平台要嘛證明自己的價值，要嘛被砍掉之後，所剩下的成果。

TL;DR

• 六個平台，六種不同的義務：iPhone（預設）、iPad（尺寸類別適應）、Mac（視窗／選單列／鍵盤慣例）、Watch（執行階段契約）、Vision（空間心智模型）、TV（焦點引擎）。
• 每多一個目標平台，都會增加測試範圍、設計工作、無障礙與後續發布協調。Xcode的「新增平台」勾選方塊掩蓋了這些成本。
• 對的測試標準是使用者價值測試，而非技術測試：使用者在那個平台上執行此App是否真的能獲益？如果答案是「它在那邊也能跑」，就砍掉。
• 大多數App應該推出於一到三個平台。四到六個並不常見，唯有當每個平台都真正提供其他平台無法傳遞的使用者價值時，才能贏得這個位置。

iPhone是預設選項

每一款Apple App的起點都是iPhone，否則它根本不會起步。iPhone擁有最大的安裝基數、最精緻的無障礙介面、透過App Store最強大的發行管道，以及最具標準性的SwiftUI設計語言。我推出的每一個叢集App都在iPhone上執行。沒有任何一款是以非iPhone優先的設計推出。

iPhone的使用者價值測試：使用者會在手機上開啟這款App嗎？對於幾乎所有消費類別來說，答案都是肯定的。健康與健身App存在於手機上。生產力工具存在於手機上。遊戲存在於手機上。通訊工具存在於手機上。預設是iPhone，因為手機就是使用者所在之處。

例外情況是開發工具（Xcode、Terminal）以及需要操作空間的創意工具（Final Cut、Logic）。這些App從Mac起步，唯有在有明確銜接情境時才會贏得iPhone的陪伴角色（運動時Watch量測心率、手機顯示圖表，或是相機接續互通）。對消費軟體而言，iPhone優先沒有討論的餘地。

iPad不只是像素更多的iPhone

通用二進位檔與尺寸類別讓UIKit iPhone App得以透過尺寸類別斷點推出於iPad。SwiftUI則透過@Environment(\.horizontalSizeClass)與NavigationSplitView讓同樣的事情變得更容易。¹「推出至iPad」的技術成本很低。產品成本的問題在於：這款App真的配得上iPad更大的畫布嗎？

iPad-yes的三個訊號：

App讓使用者閱讀或建立想要更大螢幕呈現的內容。閱讀類App（書籍、新聞、漫畫、長篇文件）。繪圖／繪畫類App（Procreate）。搭配Apple Pencil的筆記類（Notability、GoodNotes）。Get Bananas贏得iPad的位置，是因為帶有分區的購物清單在更寬的畫布上比在窄畫面上更實用；iPad的設計將相同的分區清單適配到更大的區域。

App與iPhone或Mac之間有銜接價值。Apple的備忘錄、提醒事項與郵件都贏得iPad的位置，因為使用者期待連續性。Return的冥想歷史紀錄在iPad上贏得位置也是同樣的道理：使用者從iPhone開始，計時器運行時順手瞄一眼iPad。

App具備iPad原生的輸入支援能力。用Apple Pencil素描或手寫。在更大表面上的多指手勢。受益於以拼貼為基礎佈局的Stage Manager工作流程。如果該支援能力在iPhone上不存在，那麼iPad這個目標平台就贏得了它的位置。

iPad-no的訊號：

單欄內容在放大尺度上沒有額外價值。冥想計時器的主要視圖就是一個計數與一個按鈕。iPad讓兩者都變大；那不算是功能。快速記錄飲水量的追蹤工具也是如此；在五秒鐘的記錄過程中，更寬的螢幕並不會改變使用者所做的事。

仰賴iPhone專屬硬體的App（Dynamic Island、某些Pro機種獨有的相機格式、iPhone外型握持的人因設計）。這些設計假設轉換得很差；要嘛重新設計，要嘛跳過此目標平台。

使用者已經在Mac上有更好歸屬地的App。沒有鍵盤支援的iPad程式碼編輯器，是Mac App的閹割版。除非設計能在iPad的特定輸入模型上贏得自己的位置，否則跳過此目標平台。

Mac代表視窗、選單列與鍵盤慣例

透過原生macOS目標或「Designed for iPad」（Mac Catalyst則是將UIKit程式碼帶到Mac上的UIKit對應路徑）推出於Mac的SwiftUI App，雖然能在macOS上執行，卻不會產出真正的Mac App。²真正的Mac App會尊重視窗縮放語意、選單列（在SwiftUI中是配合CommandMenu與CommandGroup建構器的.commands { } Scene修飾器）、鍵盤捷徑、macOS檔案選擇器、與Finder的拖放，以及Mac原生的分享。³略過其中任何一項，所產生的就是「視窗中的iPad App」體驗，Mac使用者一眼就能看出並做出評斷。

Mac-yes的訊號：

使用者會在App中花費時間，且會因為它是真正的桌面視窗而獲益。Get Bananas在Mac上贏得位置，是因為在書桌前編輯一份長購物清單的使用者，能受惠於配備鍵盤導覽的真正視窗。Return在Mac上贏得位置，是因為想在工作機器上執行冥想計時器的使用者，能受惠於真正的選單列App，或一個固定在特定角落的視窗。

多視窗或多文件的工作流程。附帶分割窗格的程式碼編輯器。並排顯示參考圖片的相片編輯器。試算表。這些都無法在iPad或iPhone上以正確形態存活；Mac才是合適的平台。

鍵盤驅動的互動。忽略鍵盤的Mac SwiftUI App只是徒有Mac App之名。Cmd+N新增、Cmd+W關閉、Tab切換焦點、方向鍵選取。這個成本是針對每個App的：每個Mac目標都需要一個經過深思熟慮的鍵盤介面。

Mac-no的訊號：

App是小型、單一任務的工具，無法因視窗而獲益。使用者每天執行五分鐘一次的早晨計時器，不需要Mac目標平台。使用者可以在Mac旁邊的iPhone上執行它。

iPhone造型的UI根本無法轉換的App。相機App。Apple Watch同伴App。輸入模型以觸控為先、且鍵盤滑鼠對應方式比直接觸碰手機更糟糕的App。

團隊無法承諾持續性的Mac專屬維護。Mac版本的審查方式與iPhone版本不同。macOS的更新週期、Gatekeeper的簽署、公證、針對Mac版本的App Store審查，每一項都會增加團隊必須編列預算的發布週期工作。如果團隊不願編列這份預算，就跳過此目標平台。

Apple Watch是一份執行階段契約

Watch是「推出至此」這個指令會主動誤導人的平台。Watch的執行階段模型，在watchOS執行階段是一份契約，而非背景任務中有詳盡說明，與iOS根本不同：手腕一放下，系統就會暫停App，只有特定的session類型（WKExtendedRuntimeSession的self-care、mindfulness、physical-therapy、alarm，再加上HKWorkoutSession的workout-processing與潛水session的underwater-depth）能在暫停後繼續執行。⁴沒有執行階段策略的Watch目標平台，在第二次使用時就會失靈。

Watch-yes的訊號：

App具備watchOS執行階段模型認可的session形態。冥想計時器（mindfulness session）。健身App（具備workout-processing背景模式的HKWorkoutSession）。智慧鬧鐘（alarm）。物理治療與自我照護App（對應的session類型）。Return推出於Watch，是因為冥想能乾淨地對應到mindfulness；Watch App能讓計時器在手腕放下時繼續運行，因為執行階段契約允許這麼做。

使用者真心希望以手腕作為輸入介面。運動時的心率檢視器。不必拿出手機就能啟動的計時器。一眼浮現資訊的複雜功能（complication）。Get Bananas推出於Watch，作為一個與iPhone標準商店配對的快速清單檢查介面；像Reps這類健身App之所以贏得Watch目標位置也是同樣的道理，因為在手腕上記錄一組訓練比從口袋裡掏出手機更快。

同伴App的價值是真實的。有些Watch App主要存在的目的是作為iPhone驅動資料的顯示介面（例如食譜計時器，由iPhone執行計時、Watch顯示剩餘秒數）。這些App只有在跨裝置同步建構得誠實（在單一事實來源：SwiftData + MCP + iCloud中有說明），且Watch視圖確實做了超越鏡像的實質工作時，才贏得自己的位置。

Watch-no的訊號：

App沒有可主張的session類型。Watch上的閱讀App只是徒有Watch App之名。使用者無法在手腕上閱讀一本書；執行階段模型不會延展那個session。跳過。

團隊無法承諾watchOS專屬的除錯。Watch的除錯有獨特的痛苦：模擬器行為與真實裝置行為的分歧，只會在真正的Apple Watch於手腕放下狀況下才浮現。如果團隊沒有硬體與測試意願，Watch目標就會以失靈的狀態出貨。

資料模型不符合跨裝置同步的封套。iPhone至Watch的跨裝置同步通常是用WatchConnectivity處理即時狀態，並用NSUbiquitousKeyValueStore處理小型持久化狀態（Return使用後者進行session歷史同步；在多平台上架文章中有說明）。該儲存空間在所有鍵上有1 MB的上限，且最多1024個鍵。⁵如果App的session狀態無法塞進那個封套，Watch目標就需要不同的同步架構，這是一筆真正的工程投資。

Vision是空間心智模型

Vision Pro會誘惑App以一塊在3D空間中漂浮的平面板的形式推出。那塊平面板是一個SwiftUI視窗，而visionOS上的SwiftUI讓推出它變成一鍵操作。但那塊平面板就是一個更糟的iPad。該平台真正的價值來自空間心智模型，這在RealityKit與空間心智模型中有說明，內容存在於房間裡，而不是在那塊平面板上。

Vision-yes的訊號：

App具備受惠於存在於房間裡的3D內容。使用者可以繞著走的虛擬雕塑。貼合在真實牆面上的捲尺。將姿勢提示投影到使用者身體鏡像影像上的健身教練。在visionOS上出現的多數叢集App，是透過「Designed for iPad」相容性而非原生visionOS目標來實現；那種相容性對使用者來說沒問題，但並不會讓App成為Vision原生體驗。RealityKit的空間心智模型文章主張，贏得這個平台代表的不只是在它上面執行而已。

手部追蹤是合適的輸入模型。捏取拿放、雙手縮放、半空中繪圖。visionOS提供了其他平台沒有的輸入支援能力；贏得visionOS位置的App會充分發揮這項能力。

App能處理空間特有的介面（鎖定畫面對應物、沉浸式空間、ornaments）。只是把iPhone UI浮在Vision上的生產力App，在使用者擁有該裝置的第一天就成了視覺雜訊。讓使用者持續回流的App，是那些善用空間介面的App。

Vision-no的訊號：

App根本就是平面板形狀，且完全不會因深度而獲益。筆記App、聊天App、設定工具。visionOS會執行它們；但使用者沒有理由要在visionOS上而非iPad上使用它們。跳過。

開發團隊沒有visionOS專屬測試。visionOS是安裝基數最小、模式最脆弱的平台；沒有真實裝置就要測試Vision目標難度獨特，比watchOS的情況更甚。

隱私與在場感的疑慮主導。揭露健康資訊的App。敏感的職場工具。visionOS裝置在家庭成員之間共享的方式與iPhone不同；會浮現私密資訊的App，在那裡需要的姿態與在iPhone上不同。

Apple TV是焦點引擎

TV App由Siri Remote的焦點引擎驅動：使用者用遙控器移動焦點高亮、按下選擇，從未見過觸控互動。tvOS上的SwiftUI透過.focusable(...)修飾器、@FocusState屬性包裝器，以及用於狀態繫結的.focused(...)來支援這項機制，但每一款TV App都需要從零開始的焦點設計。⁶iPhone的點擊與捲動模型無法轉換。

TV-yes的訊號：

App適用於在電視觀看距離下進行內容消費。串流影片（Apple TV+、Netflix）。相片幻燈片。使用者用遙控器操控的家庭遊戲類App。使用者在沙發上、螢幕在遠方、輸入稀疏，TV是合適的平台。

App具備iPhone所沒有的「向後靠」使用情境。使用者跟著做的健身影片。使用者在爐邊參考的烹飪App。使用者邊聽邊睡的睡前故事。這些情境都無法靠一支立在咖啡桌上的手機妥善服務。

互動模型符合稀疏、焦點驅動的導覽。讓使用者一次挑選一項的項目清單。一格格的選項。線性的播放流程。任何比這更複雜的事情，多點觸控手勢、細緻的文字輸入、拖放，在tvOS上都行不通，意味著目標平台選錯了。

TV-no的訊號：

App需要文字輸入。透過遙控器在TV上輸入文字，是任一Apple平台上最糟的輸入模型之一。如果App需要的不只是一個搜尋框，就跳過TV。

App的價值取決於使用者雙手能空出來做其他事。健身追蹤。健康監測。即時協作。TV是螢幕，不是穿戴裝置。

對於安裝基數而言，維護成本太高。相對於iOS，tvOS的安裝基數很小。開發成本是真實的（焦點設計、獨立測試、針對tvOS的App Store審查）。對於大多數App來說，這筆帳划不來。一款冥想App只有在具備真正的「我在沙發上時就讓它以低亮度留在螢幕上」模式且使用情境真的會回饋這份努力時，才贏得Apple TV的位置；缺少那個模式，即使是計時器能乾淨地對應到TV「向後靠」模式的App，也不配得起這份維護帳單。

矩陣的實際情況

每個叢集App的實際矩陣：

這個模式：每一列既是刻意的加入，也同樣是刻意的砍除。Return延伸到六個平台，是因為每一個都透過特定的使用者價值測試證明了正當性；那些只在iPhone上的App待在原處，因為其他平台都不適合。同一套工具鏈、不同的產品、不同的矩陣。

三個讓矩陣可持續的架構決策

三個讓多平台App不至於在自身重量下崩塌的模式：

共享核心使用#if os(iOS)、#if os(macOS)、#if os(watchOS)（以及其他類似條件）來圍住平台特有的介面。⁷核心領域邏輯（資料模型、業務規則、同步）在所有平台上都能編譯。平台特有的UI藏在編譯期條件後面。SwiftUI的@available(iOS 26.0, macOS 26.0, ...)涵蓋OS版本的差異；在平台之間真正出現分歧的介面（iPhone上沒有對應物的Mac選單列、iPad上沒有對應物的Watch複雜功能）會以#if os(...)為界，放在各個目標專屬群組中的獨立檔案裡。

跨裝置同步走單一基底，依領域選擇。NSUbiquitousKeyValueStore用於跨裝置的小型session層級狀態（Return用此處理跨裝置計時器狀態）。iCloud Drive JSON檔案用於跨程序橋接（Get Bananas配合其MCP伺服器使用此方式，在單一事實來源中有說明）。SwiftData用於程序內狀態。各領域混用不同基底沒問題；但在同一個領域裡使用兩種基底，就是會導致漂移的失敗模式。

每個平台都有針對各App明確記錄的拒絕模式。「除非使用情境具備向後靠模式，否則我們不推出至TV。」「除非App使用RealityKit而非平面板，否則我們不推出至Vision。」「沒有session類型，我們不推出至Watch。」這些拒絕是針對每個App記錄、並一致套用的專案決策，秉持我拒絕書寫的主題的精神。

加平台是錯的時機

三種較容易的路徑就是錯誤路徑的情況。

團隊加入目標平台只是因為工具鏈讓這件事很容易。Xcode的「複製目標」精靈讓加入Mac或visionOS目標變成四下點擊的操作。那四下點擊不包含設計審查、無障礙稽核、App Store截圖製作、後續發布協調，或是各平台測試。從精靈推出且未伴隨上述工作的目標平台，第一天上架就是失靈狀態。

團隊把目標平台數量當成地位訊號。「我們在五個Apple平台上推出」在發布貼文裡聽起來令人印象深刻。但發布貼文不會在使用者裝置上執行；App才會。一款在兩個平台上都做到位的App，是比一款在五個平台上都被拉伸的App更好的產品。

團隊低估了後續維護成本。每個Apple平台每年都會發布主要OS更新。一款五平台App每年要因應五組發行說明、要測試五組行為變更、要保持五組App Store後設資料的最新狀態。成本會複利累積；推出至全部五個平台、卻沒有頻寬維護它們的團隊，會在其中三個平台上產出緩慢衰退的產品。

這個模式對於上架在iOS 26+的App代表什麼

三個重點。

1. 平台納入是產品決策，先於工程決策。Xcode勾選方塊是工程面；使用者價值測試是產品面。如果無法明確回答「使用者在那個平台上執行此App是否真的會獲益」，那個目標就會被砍掉。

2. 每個平台帶來特定義務：尺寸類別（iPad）、視窗／選單／鍵盤（Mac）、執行階段契約（Watch）、空間模型（Vision）、焦點引擎（TV）。略過這些義務，會產出在Mac上的iPad App、在Vision上的手機App、在Watch上的iPhone App，全都是該平台實際使用者一眼可見的失敗。

3. 大多數App應該推出於一到三個平台。四到六個並不常見，唯有當每個平台真的提供使用者價值時才贏得這個位置。叢集中的App跨度從一個到六個；六平台的案例（Return）是稀有的端點，那裡每多一個平台都是經過獨立的產品決策、有自己的使用者價值測試。

完整的Apple Ecosystem叢集：用於Apple Intelligence介面的型別化App Intents；用於agent介面的MCP伺服器；兩者之間的路由問題；用於App內裝置端LLM功能的Foundation Models；執行階段對工具鏈LLM的區別；三個介面的綜合論述；單一事實來源模式；用於Xcode整合的兩個MCP伺服器；Apple開發中的hooks；Live Activities；watchOS執行階段契約；SwiftUI內部；RealityKit的空間心智模型；SwiftData綱要紀律；Liquid Glass模式；多平台上架；我拒絕書寫的主題。中樞位於Apple Ecosystem系列。如需更廣泛的iOS搭配AI agent情境，請參見iOS Agent開發指南。

FAQ

我該如何決定是否新增Apple平台目標？

請問使用者是否真的因為在那個平台上執行該App而獲益，而不是工具鏈是否允許。Xcode的勾選方塊是技術面；使用者價值測試是產品面。每個平台都帶來特定義務（尺寸類別、視窗／選單、執行階段契約、空間模型、焦點引擎）以及特定的維護成本。如果答案是「它在那邊也能跑」，正確的做法通常是跳過該目標。

我應該推出至全部六個Apple平台嗎？

通常不應該。大多數App受惠於一到三個平台。四到六個並不常見，唯有每個平台都真正提供使用者價值時才贏得這個位置（Return推出至全部六個，是因為mindfulness session契合Watch、計時器作為書桌伴侶契合iPad與Mac、visionOS契合沉浸式模式、TV契合向後靠的沙發使用情境）。對於大多數App來說，tvOS的互動模型與visionOS的空間需求都不契合，正確的做法是跳過那些目標平台。

新增iPad目標時最常見的錯誤是什麼？

把iPad當成「像素更多的iPhone」。沒有經過尺寸類別適應，就直接放上iPad的SwiftUI iPhone App，會產生一個拉伸過的單欄UI，iPad使用者馬上就會評斷為敷衍之作。對的模式是讀取@Environment(\.horizontalSizeClass)、把佈局適配到較大畫布上（在合理之處透過NavigationSplitView採用兩欄，否則使用具有舒適間距的單一清單），並把Apple Pencil與多指支援能力視為iPad特有的價值。

為什麼Apple Watch與其他平台如此不同？

watchOS沒有iOS的背景執行模型。手腕一放下，系統就會暫停App，只有特定的session類型（WKExtendedRuntimeSession的self-care、mindfulness、physical-therapy、alarm，再加上HKWorkoutSession的workout-processing）能在暫停後繼續執行。⁴沒有乾淨session類型的App，會產出第二次使用就失靈的體驗。叢集的watchOS執行階段文章詳細說明了該契約。

跨裝置同步如何在平台矩陣中運作？

三種基底：NSUbiquitousKeyValueStore用於小型鍵值狀態（設定、上次選取的分頁、跨裝置計時器狀態），⁵iCloud Drive檔案用於跨程序橋接（Get Bananas + MCP伺服器模式），SwiftData用於程序內狀態。每個領域選一種基底；在同一個領域裡混用兩種會產生漂移。叢集的單一事實來源文章逐步解析該決策矩陣。

References