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起步，只有在存在明确的衔接场景时才会赢得iPhone伴侣应用的地位（例如Apple Watch在锻炼时记录心率而手机展示图表，或Camera Continuity）。对消费类软件而言，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运行时是契约，而非后台任务中有详细介绍，它与iOS的运行时模型存在根本性差异：手腕放下，系统挂起应用，只有特定的会话类型（mindfulness、workout-processing、alarm等）才能在挂起后继续运行。没有运行时方案的Watch目标，第二次使用时就坏了。

应该上Watch的信号：

应用具备watchOS运行时模型认可的会话形态。冥想计时器（mindfulness会话）。健身应用（workout-processing）。闹钟（alarm）。导航（navigation会话类型）。Return在Watch上发布，是因为冥想干净利落地映射到mindfulness；Watch应用能够穿越手腕放下事件保持计时器运行，因为运行时契约允许这样做。

用户真心希望把手腕作为输入界面。锻炼时的心率查看器。不掏出手机就能启动的计时器。能够一瞥呈现信息的复杂功能。Get Bananas在Watch上发布，作为快速勾选清单的界面，与iPhone上的标准商店配对；像Reps这样的健身应用赢得Watch名额也是同样的理由，因为在手腕上记录一组动作比从口袋里掏出手机更快。

伴侣应用价值是真实存在的。有些Watch应用主要作为iPhone驱动数据的展示界面（例如，iPhone运行计时器、Watch显示剩余倒计时的食谱计时器）。只有在跨设备同步以诚实的方式构建（详见单一事实来源：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和空间心智模型，在这种模型下，内容存在于房间里而非面板内。

应该上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的信号：

应用需要文本输入。通过遥控器输入文本是所有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复杂功能）在目标专属分组中拥有各自的文件。

跨设备同步走单一基底，按领域选择。NSUbiquitousKeyValueStore用于跨设备的小型会话级状态（Return用它存储跨设备计时器状态）。iCloud Drive JSON文件用于跨进程桥接（Get Bananas和它的MCP服务器一起使用，详见单一事实来源）。SwiftData用于进程内状态。按领域混用基底是可以的；同一领域用两种基底就是产生漂移的失败模式。

每个平台都有按应用记录的明确拒绝模式。“除非使用场景具备靠着看的模式，否则我们不会上TV。”“除非应用使用RealityKit而非面板，否则我们不会上Vision。”“没有会话类型就不会上Watch。”这些拒绝是按应用捕获并被一致执行的项目决策，秉承我拒绝写什么的精神。

何时新增平台是错误的

三种”更轻松的路径就是错误路径”的情形。

团队因为工具链让事情变简单而新增目标。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开发的钩子；实时活动；watchOS运行时契约；SwiftUI内部机制；RealityKit的空间心智模型；SwiftData模式纪律；Liquid Glass模式；多平台发布；我拒绝写什么。中心枢纽位于Apple生态系统系列。要了解更广泛的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运行时文章详细介绍了这一契约。

跨设备同步在平台矩阵中是如何工作的？

三种基底：NSUbiquitousKeyValueStore用于小型键值状态（设置项、上次选中的标签页、跨设备计时器状态），iCloud Drive文件用于跨进程桥接（Get Bananas + MCP服务器模式），SwiftData用于进程内状态。每个领域选用一种基底；同一领域同时使用两种会产生漂移。集群中的单一事实来源文章走过了这套决策矩阵。