Apple 平台矩陣：哪些目標值得擁有哪種應用程式

Apple 推出六個消費者運算平台,開發者可以用單一 Swift 程式碼庫來鎖定:iPhone、iPad、Mac、Watch、Vision 和 TV。SwiftUI 加上 iOS 26 工具鏈,讓加入任一平台變成 Xcode 中勾選核取方塊的操作。而這個核取方塊正是陷阱。每多一個目標都是一份義務,而非一項功能:每個目標都會擴大設計、測試、無障礙、執行時模型以及後續維護的範圍。一個應用程式合適的目標數量,比框架允許的還要少。

這個叢集中的應用程式採用不同的組合。Return 推出於六個平台(iPhone、iPad、Mac、Watch、Vision、TV)。Get Bananas 推出於四個平台(iPhone、iPad、Mac、Watch)。Reps 與 Water 處於發布前階段,編譯了多個目標,但應用程式會在上市前縮減範圍。Ace Citizenship 與 Tappy Color 各自只在 iPhone 上推出。同一位開發者、同一套工具鏈,卻有六種不同的平台決策。這些決策遵循規則;這些規則值得擁有一張共享的地圖。

本文將指明這些規則。每個平台都要透過該平台真正帶來的具體使用者價值來贏得入選資格,而不是「能編譯通過」就行。撐到上市的矩陣,正是每個目標經過自我證成或被裁掉之後所剩下的成果。

TL;DR

• 六個平台、六種不同義務:iPhone(預設)、iPad(尺寸類別適應)、Mac(視窗/選單/鍵盤慣用法)、Watch(執行時合約)、Vision(空間心智模型)、TV(焦點引擎)。
• 每多一個目標都會增加測試範圍、設計工作、無障礙與後續發布協調工作。Xcode 的「新增平台」核取方塊隱藏了這些成本。
• 真正該做的測試是使用者價值測試,而非技術測試:使用者在那個平台上執行此應用程式,是否真的能受惠?如果答案是「在那邊也能跑」,那就裁掉。
• 大多數應用程式應該推出一到三個平台。四到六個並不常見,只有在每個平台都真正帶來其他平台無法提供的使用者價值時,才能贏得席位。

iPhone 是預設選項

每個 Apple 應用程式不是從 iPhone 開始,就是不會開始。iPhone 擁有最大的安裝量、最精緻的無障礙介面、透過 App Store 最強的發行管道,以及最正統的 SwiftUI 設計語言。我推出的每個叢集應用程式都在 iPhone 上執行。沒有一個是以非 iPhone 優先的方式設計推出的。

iPhone 的使用者價值測試:使用者會在手機上開啟這個應用程式嗎?對幾乎所有消費者類別而言,答案是會。健康與健身應用程式活在手機上。生產力工具活在手機上。遊戲活在手機上。通訊工具活在手機上。預設是 iPhone,因為手機就是使用者所在之處。

例外是開發工具(Xcode、Terminal)以及需要空間的創作工具(Final Cut、Logic)。這些從 Mac 起步,只有在有清晰的接力使用情境時(例如運動時 Watch 偵測心率、手機顯示圖表;Camera Continuity)才贏得 iPhone 伴隨應用程式的席位。對消費性軟體而言,iPhone 優先沒有討論餘地。

iPad 不是「畫素更多的 iPhone」

Catalyst 讓 UIKit 的 iPhone 應用程式可以透過尺寸類別斷點推到 iPad 上。SwiftUI 透過 @Environment(\.horizontalSizeClass) 與 NavigationSplitView 讓同樣的事情變得更簡單。「推到 iPad」的技術成本很低。產品成本則是另一個問題:這個應用程式真的配得上 iPad 較大的畫布嗎?

三個值得推到 iPad 的訊號:

應用程式所閱讀或創作的內容,讓使用者想要更多的螢幕空間。 閱讀類應用程式(Books、新聞、漫畫、長文件)。繪畫類應用程式(Procreate)。搭配 Apple Pencil 的筆記應用程式(Notability、GoodNotes)。Get Bananas 贏得 iPad 席位,因為帶有分區的購物清單在較寬的畫布上比在窄畫布上更實用;iPad 設計把同一份分區清單適配到較大的版面。

應用程式與 iPhone 或 Mac 之間具有接力價值。 Apple Notes、Reminders 與 Mail 都贏得 iPad 席位,因為使用者預期延續性。Return 在 iPad 上的冥想歷史記錄出於同樣理由贏得席位:使用者從 iPhone 開始,計時器運行時瞥一眼 iPad。

應用程式擁有 iPad 原生的輸入適配。 用於素描/手寫的 Apple Pencil。較大表面上的多指手勢。受惠於並排佈局的 Stage Manager 工作流程。如果 iPhone 上沒有對應的輸入方式,iPad 目標就贏得了它的位置。

iPad 不該推的訊號:

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

仰賴 iPhone 特有硬體的應用程式(鎖定螢幕、動態島、特定 iPhone 配置中的 ProMotion、特定相機格式)。這些設計假設轉換性差;要麼重建設計,要麼跳過這個目標。

使用者在 Mac 上已有更佳目的地的應用程式。 沒有鍵盤支援的 iPad 程式碼編輯器是 Mac 應用程式的殘缺版本。除非設計能在 iPad 特定的輸入模型上贏得自己的位置,否則跳過這個目標。

Mac 等於視窗、選單列與鍵盤慣用法

透過 Mac Catalyst 或「Designed for iPad」推到 Mac 的 SwiftUI 應用程式雖然能在 macOS 上執行,但並不會產出真正的 Mac 應用程式。真正的 Mac 應用程式會尊重視窗縮放語意、選單列(SwiftUI 中的 Commands(content:))、鍵盤捷徑、macOS 檔案選擇器、與 Finder 的拖放功能,以及 Mac 原生的分享機制。略過其中任何一項,就會做出 Mac 使用者一眼看穿並予以批評的「視窗中的 iPad 應用程式」體驗。

值得推到 Mac 的訊號:

使用者在應用程式中花費時間,且能受惠於它成為真正的桌面視窗。 Get Bananas 在 Mac 上贏得席位,因為使用者在書桌前編輯一份長購物清單時,會受惠於擁有鍵盤導覽的真正視窗。Return 在 Mac 上贏得席位,因為想在工作機上執行冥想計時器的使用者,會受惠於真正的選單列應用程式或固定在特定角落的視窗。

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

鍵盤驅動的互動。 在 Mac 上忽略鍵盤的 SwiftUI 應用程式,只是徒有其名的 Mac 應用程式。Cmd+N 新建、Cmd+W 關閉、Tab 切換焦點、方向鍵選擇。成本逐個應用程式累加:每個 Mac 目標都需要經過深思熟慮的鍵盤介面。

Mac 不該推的訊號:

應用程式是小型、單一任務的工具,從視窗化中得不到好處。 使用者一天執行一次、每次五分鐘的晨間計時器,不需要 Mac 目標。使用者可以在 Mac 旁邊的 iPhone 上執行它。

iPhone 形狀的 UI 從根本上無法轉換的應用程式。 相機應用程式。Apple Watch 伴隨應用程式。輸入模型以觸控為主、且鍵盤/滑鼠等價物會比觸碰手機更糟的應用程式。

團隊無法投入持續的 Mac 專屬維護。 Mac 版本的審視標準與 iPhone 版本不同。macOS 的更新週期、為 Gatekeeper 簽章、公證、Mac 專屬的 App Store 審查,每一項都會增加團隊必須編列的發布週期工作量。如果團隊不會編列這份預算,就跳過這個目標。

Apple Watch 是執行時合約

Watch 是「推上去就好」這句話最具誤導性的平台。Watch 的執行時模型(詳細討論見watchOS Runtime Is a Contract, Not a Background Task)與 iOS 從根本上不同:手腕落下時系統會暫停應用程式,只有特定的工作階段類型(mindfulness、workout-processing、alarm 等)能在暫停後繼續執行。沒有執行時策略的 Watch 目標,在第二次使用時就壞掉了。

值得推到 Watch 的訊號:

應用程式擁有 watchOS 執行時模型認得的工作階段形狀。 冥想計時器(mindfulness 工作階段)。健身應用程式(workout-processing)。鬧鐘(alarm)。導航(navigation 工作階段類型)。Return 推到 Watch,是因為冥想可乾淨地對應到 mindfulness;Watch 應用程式能在手腕落下時保持計時器運轉,因為執行時合約允許這麼做。

使用者真心希望以手腕作為輸入介面。 運動時的心率檢視器。不必拿出手機就能啟動的計時器。一眼能看到資訊的複雜功能(complication)。Get Bananas 推到 Watch,是搭配 iPhone 標準商店的快速清單核對介面;像 Reps 這類運動應用程式贏得 Watch 目標也是同樣理由,因為在手腕上記錄一組訓練,比把手機從口袋掏出來更快。

伴隨應用程式的價值是真實的。 有些 Watch 應用程式主要存在的目的,是作為 iPhone 驅動資料的顯示介面(例如食譜計時器:iPhone 在跑計時、Watch 顯示剩餘秒數)。這類應用程式只有在跨裝置同步是誠實實作的(詳見Single Source of Truth: SwiftData + MCP + iCloud),且 Watch 視圖在「鏡像顯示」之外確實做了實事,才贏得席位。

Watch 不該推的訊號:

應用程式沒有可主張的工作階段類型。 Watch 上的閱讀應用程式只是徒有其名的 Watch 應用程式。使用者無法在手腕上閱讀一本書;執行時模型也不會延伸這個工作階段。跳過。

團隊無法投入 watchOS 專屬除錯。 Watch 除錯獨具痛苦:模擬器行為與真實裝置行為的差異,只有在真實 Apple Watch 處於手腕落下狀態時才會浮現。如果團隊沒有硬體、也不願意在硬體上測試,Watch 目標推出時就是壞的。

資料模型不適合 1MB 的跨裝置同步信封。 從 iPhone 到 Watch 的跨裝置同步通常透過 NSUbiquitousKeyValueStore(在多平台上市文章中討論)。該儲存體有總計 1MB + 每個值 1MB + 1024 個鍵的限制。如果應用程式的工作階段狀態塞不進這個信封,Watch 目標就需要不同的同步架構,那是一筆真實的工程投資。

Vision 是空間心智模型

Vision Pro 誘惑應用程式以 3D 空間中漂浮的扁平面板形式上市。那塊面板是一個 SwiftUI 視窗,visionOS 上的 SwiftUI 讓推出它變成一鍵的操作。那塊面板是一個更糟的 iPad。這個平台真正的價值來自空間心智模型(詳見RealityKit and the Spatial Mental Model),內容存在於房間裡,而不是在面板裡。

值得推到 Vision 的訊號:

應用程式擁有受惠於存在於房間中的 3D 內容。 一座使用者可以繞著走的虛擬雕塑。一條鋪在真實牆面上的捲尺。一位將動作提示投射到使用者身體鏡像上的健身教練。大多數出現在 visionOS 上的叢集應用程式,是透過「Designed for iPad」相容性而非原生 visionOS 目標來實現的;對使用者而言這種相容性沒問題,但這並不會讓應用程式成為 Vision 原生體驗。RealityKit 的空間心智模型一文主張,贏得這個平台的意義遠大於僅僅在它上面執行。

手部追蹤是合適的輸入模型。 捏合抓取、雙手縮放、半空中繪製。visionOS 提供了其他平台都沒有的輸入適配;贏得 visionOS 席位的應用程式會深入運用它。

應用程式處理空間特有的介面(類似鎖定螢幕、沉浸式空間、裝飾物)。 只是讓 iPhone UI 漂浮在 Vision 上的生產力應用程式,在使用者拿到裝置的第一天就是顯眼的雜訊。能讓使用者持續回流的應用程式,是那些善用空間介面的應用程式。

Vision 不該推的訊號:

應用程式從根本上是面板形狀,完全不會受惠於景深。 筆記應用程式、聊天應用程式、設定工具。visionOS 會跑這些應用程式;但使用者沒有理由在 visionOS 上用而不是在 iPad 上用。跳過。

開發團隊沒有 visionOS 專屬測試。 visionOS 是安裝量最小、模式最脆弱的平台;沒有真實裝置就測試 Vision 目標獨具困難,程度甚至超過 watchOS 的情況。

隱私與在場顧慮主導。 健康揭露類應用程式。敏感的職場工具。visionOS 裝置會在家庭成員間共用,方式與 iPhone 不同;會呈現私人資訊的應用程式,在那裡需要與在 iPhone 上不同的姿態。

Apple TV 是焦點引擎

TV 應用程式由 Siri Remote 的焦點引擎驅動:使用者透過遙控器移動焦點高亮、按下選擇,從不會看到觸控互動。tvOS 上的 SwiftUI 透過 .focusable(...) 修飾符、@FocusState 屬性包裝器以及用於狀態繫結的 .focused(...) 來支援這一點,但每個 TV 應用程式都需要從零開始的焦點設計。iPhone 的點擊與滾動模型無法轉換過來。

值得推到 TV 的訊號:

應用程式的用途是在電視觀看距離下進行內容消費。 串流影片(Apple TV+、Netflix)。相片幻燈片秀。使用者用遙控器操控的家庭遊戲應用程式。使用者坐在沙發上、螢幕在遠方、輸入稀疏,TV 是合適的平台。

應用程式擁有 iPhone 沒有的「向後靠」使用情境。 使用者跟著做的健身影片。使用者在爐邊參考的烹飪應用程式。使用者入睡時收聽的睡前故事。咖啡桌上立著的手機都無法妥善服務這些用途。

互動模型契合稀疏、焦點驅動的導覽。 使用者一次選一項的項目清單。選項網格。線性的播放流程。比這更複雜的東西,例如多點觸控手勢、細緻的文字輸入、拖放,都無法在 tvOS 上運作,意味著目標選錯了。

TV 不該推的訊號:

應用程式需要文字輸入。 透過遙控器在 TV 上輸入文字,是任何 Apple 平台上最糟糕的輸入模型之一。如果應用程式所需的不只是搜尋框,就跳過 TV。

應用程式的價值取決於使用者雙手得空做其他事。 健身追蹤、健康監測、即時協作。TV 是一塊螢幕,而非穿戴裝置。

相對於安裝量,維護成本過高。 tvOS 相對於 iOS 的安裝量很小。開發成本是真實的(焦點設計、獨立測試、tvOS 的 App Store 審查)。對大多數應用程式而言,這筆帳不划算。冥想應用程式只有在擁有真正的「以低亮度留在螢幕上、讓我坐在沙發上看著」模式、且該使用情境真的會有回報時,才贏得 Apple TV 席位;少了那個模式,即便是計時器能乾淨對應到 TV 向後靠模式的應用程式,也不配付出維護費用。

矩陣的實際樣貌

每個叢集應用程式的實際矩陣:

模式很清楚:每一列既是一份慎重的加入,也是一份慎重的裁減。Return 達到六個平台,因為每一個都通過了具體的使用者價值測試;只在 iPhone 上的應用程式停留在那裡,因為其他平台都不適合。同一套工具鏈、不同的產品、不同的矩陣。

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

三個避免多平台應用程式因自身重量而崩塌的模式:

共享核心透過 #if canImport(SwiftUI) && canImport(<platform>) 鎖定平台特有介面。 核心領域邏輯(資料模型、業務規則、同步)可在所有地方編譯。平台特有的 UI 隱身於編譯時條件之後。SwiftUI 的 @available(iOS 26.0, macOS 26.0, ...) 涵蓋大多數情況;真正分歧的介面(沒有 iPhone 等價物的 Mac 選單列、沒有 iPad 等價物的 Watch complication)會放在目標特有群組內各自的檔案中。

跨裝置同步透過單一基底進行,依領域選擇。 用 NSUbiquitousKeyValueStore 處理跨裝置的小型工作階段層級狀態(Return 用它處理跨裝置計時器狀態)。用 iCloud Drive JSON 檔案處理跨行程橋接(Get Bananas 與其 MCP 伺服器一起使用,詳見Single Source of Truth)。用 SwiftData 處理行程內狀態。每個領域混用基底沒問題;對同一領域使用兩種基底就是會產出漂移的失敗模式。

每個平台都有針對該應用程式明確記錄的拒絕模式。 「除非使用情境具備向後靠模式,我們不會推到 TV。」「除非應用程式使用 RealityKit 而非面板,我們不會推到 Vision。」「沒有工作階段類型,我們不會推到 Watch。」這些拒絕是針對每個應用程式所擷取並一致應用的專案決策,精神上呼應What I Refuse To Write About。

何時加平台是錯誤的

三種較簡單的路反而是錯誤的情況。

團隊因為工具鏈讓這件事變容易而新增目標。 Xcode 的「複製目標」精靈讓加入 Mac 或 visionOS 目標變成四下點擊的操作。這四下點擊不包括設計審查、無障礙稽核、App Store 螢幕截圖製作、後續發布協調或逐平台測試。在這些工作未一同上市的情況下,從精靈裡推出的目標一上市就是壞的。

團隊把目標數量當成地位訊號。 「我們在五個 Apple 平台上推出」在發布推文裡聽起來很厲害。發布推文不會在使用者裝置上執行;應用程式才會。一個雙平台應用程式把兩個平台都做到位,是比一個五平台卻被拉扯到變形的應用程式更好的產品。

團隊低估持續的維護工作。 每個 Apple 平台每年都會推出主要 OS 更新。一個五平台應用程式有五份發行說明要因應、五組行為變更要測試、五份 App Store 中繼資料要保持更新。成本會疊加;在沒有頻寬維護的情況下推到全部五個平台的團隊,會在其中三個平台上產出緩慢腐朽的產品。

這個模式對在 iOS 26+ 上市的應用程式意味著什麼

三個重點。

1. 平台納入是產品決策,而非工程決策。 Xcode 核取方塊是工程面;使用者價值測試是產品面。如果對「使用者在那個平台上執行此應用程式是否真的能受惠」沒有清晰答案,目標就會被裁掉。

2. 每個平台帶來具體義務:尺寸類別(iPad)、視窗/選單/鍵盤(Mac)、執行時合約(Watch)、空間模型(Vision)、焦點引擎(TV)。 跳過這些義務會做出 Mac 上的 iPad 應用程式、Vision 上的手機應用程式、Watch 上的 iPhone 應用程式,全都是平台真正使用者一眼能看見的失敗。

3. 大多數應用程式應該推出一到三個平台。 四到六個並不常見,只有在每個平台都真正帶來使用者價值時才贏得席位。叢集中的應用程式跨度從一到六;六平台的案例(Return)是證明此規則的例外,而每個額外的平台都是經過自己使用者價值測試的獨立產品決策。

完整的 Apple 生態系叢集:為 Apple Intelligence 介面提供的具型別App Intents;為代理介面提供的MCP 伺服器;兩者之間的路由問題;為應用程式內裝置端 LLM 功能提供的Foundation Models;執行時對工具 LLM 之區分;三個介面的綜合論述;單一真實來源模式;用於 Xcode 整合的兩個 MCP 伺服器;Apple 開發中的 hooks;Live Activities;watchOS 執行時合約;SwiftUI 內部結構;RealityKit 的空間心智模型;SwiftData 結構紀律;Liquid Glass 模式;多平台上市;我拒絕撰寫的主題。中心頁位於Apple Ecosystem Series。如需更廣泛的「iOS 搭配 AI 代理」脈絡,請參閱iOS Agent Development guide。

FAQ

我該如何決定是否新增一個 Apple 平台目標?

問問使用者在那個平台上執行此應用程式是否真的能受惠,而不是工具鏈是否允許。Xcode 核取方塊是技術面;使用者價值測試是產品面。每個平台都帶來具體義務(尺寸類別、視窗/選單、執行時合約、空間模型、焦點引擎)以及具體的維護成本。如果答案是「在那邊也能跑」,正確的做法通常是跳過這個目標。

我應該推到全部六個 Apple 平台嗎?

通常不該。大多數應用程式受惠於一到三個平台。四到六個並不常見,只有在每個平台都真正帶來使用者價值時才贏得席位(Return 之所以能達到全部六個,是因為 mindfulness 工作階段適合 Watch、計時器適合 iPad 與 Mac 作為書桌伴侶、visionOS 適合沉浸模式、TV 適合沙發向後靠的使用情境)。對大多數應用程式而言,tvOS 的互動模型與 visionOS 的空間需求並不契合,正確的做法是跳過這些目標。

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

把 iPad 當成「畫素更多的 iPhone」對待。把 SwiftUI iPhone 應用程式不做尺寸類別適應就丟到 iPad 上,會做出被拉伸的單欄 UI,iPad 使用者立刻會評斷為敷衍之作。正確的做法是讀取 @Environment(\.horizontalSizeClass)、把版面適配到較大的畫布(在合理之處透過 NavigationSplitView 改為兩欄,否則維持單一清單但保有舒適的間距),並把 Apple Pencil 與多指適配視為 iPad 特有的價值。

為什麼 Apple Watch 與其他平台差這麼多?

watchOS 沒有 iOS 的背景執行模型。手腕落下時系統會暫停應用程式,只有特定的工作階段類型(mindfulness、workout-processing、alarm 等)能在暫停後繼續執行。沒有乾淨工作階段類型的應用程式會做出第二次使用即崩潰的體驗。叢集中的watchOS runtime 文章詳述了這份合約。

跨裝置同步在這個平台矩陣中如何運作?

三種基底:NSUbiquitousKeyValueStore 用於小型鍵值狀態(設定、上次選取的索引標籤、跨裝置計時器狀態);iCloud Drive 檔案用於跨行程橋接(Get Bananas + MCP 伺服器模式);SwiftData 用於行程內狀態。每個領域選一種基底;對同一領域混用兩種會產出漂移。叢集中的單一真實來源文章走過完整的決策矩陣。