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

通用二进制和尺寸类让通过尺寸类断点将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握持的人体工学）。那些设计假设难以转译；要么重建设计，要么跳过这个目标。

用户在Mac上已经有更好去处的应用。 没有键盘支持的iPad代码编辑器是Mac版本的残废版。除非该设计在iPad特定的输入模型上赢得了自己的位置，否则跳过。

Mac意味着窗口、菜单栏和键盘惯用法

通过原生macOS目标或”Designed for iPad”（Mac Catalyst是将UIKit代码带到Mac的UIKit等效路径）发布到Mac的SwiftUI应用，能够在macOS上运行，但并不会产生一款真正的Mac应用。²一款真正的Mac应用尊重窗口大小调整语义、菜单栏（SwiftUI中带CommandMenu和CommandGroup构建器的.commands { } Scene修饰符）、键盘快捷键、macOS文件选择器、与Finder的拖放，以及Mac原生分享。³跳过其中任何一项,都会产生一种”窗口里的iPad应用”的体验,Mac用户能注意到并据此评判。

支持Mac的信号：

用户在应用中花费时间，并能从其作为真正的桌面窗口中受益。 Mac版Get Bananas赢得席位，因为在桌前编辑长购物清单的用户能从带键盘导航的真实窗口中受益。Mac版Return赢得席位，因为希望在工作机器上运行冥想计时器的用户能从真正的菜单栏应用或固定到特定角落的窗口中受益。

多窗口或多文档工作流。 带分屏的代码编辑器。带并排参考图像的照片编辑器。电子表格。这些在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的运行时模型有根本不同：手腕放下，系统挂起应用，只有特定的会话类型（WKExtendedRuntimeSession的self-care、mindfulness、physical-therapy、alarm，加上HKWorkoutSession的workout-processing和潜水会话的underwater-depth）才能在挂起后继续运行。⁴没有运行时方案的Watch目标在第二次使用时就会失效。

支持Watch的信号：

应用具有watchOS运行时模型识别的会话形态。 冥想计时器（mindfulness会话）。健身应用（带workout-processing后台模式的HKWorkoutSession）。智能闹钟（alarm）。物理治疗和自我护理应用（匹配的会话类型）。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目标就是有缺陷的。

数据模型不适合跨设备同步信封。 从iPhone到Watch的跨设备同步通常是用于实时状态的WatchConnectivity和用于小型持久化状态的NSUbiquitousKeyValueStore（Return使用后者进行会话历史同步；在多平台发布博文中介绍）。该存储所有键的总容量上限为1 MB，最多1024个键。⁵如果应用的会话状态无法装入该信封，Watch目标就需要不同的同步架构，那是真正的工程投入。

Vision是空间心智模型

Vision Pro诱使应用以悬浮在3D空间中的扁平面板形式发布。那个面板就是一个SwiftUI窗口，而visionOS上的SwiftUI让发布它成为一键操作。那个面板是一个更糟的iPad。该平台的真正价值来自空间心智模型，在RealityKit与空间心智模型中有详细介绍，内容存在于房间中，而非面板里。

支持Vision的信号：

应用具有可从置于房间中受益的3D内容。 用户可以绕着走的虚拟雕塑。贴在真实墙面上的卷尺。将动作提示投射到用户身体镜像上的健身教练。集群中大多数出现在visionOS上的应用是通过”Designed for iPad”兼容性而非原生visionOS目标实现的；这种兼容性对用户来说没问题，但它并不能让应用成为Vision原生体验。RealityKit的空间心智模型一文论证道，赢得这个平台不仅仅意味着在它上面运行。

手部追踪是合适的输入模型。 捏合抓取、双手缩放、在空中绘画。visionOS提供了其他平台没有的输入可供性；赢得visionOS席位的应用倾向于充分利用它。

应用处理空间特有的表面（锁屏等价物、沉浸空间、装饰物）。 仅在Vision上漂浮其iPhone UI的生产力应用，是用户使用设备第一天就能看见的杂讯。让用户不断回访的应用，是那些利用了空间表面的应用。

不支持Vision的信号：

应用本质上是面板形状的，完全无法从纵深中受益。 笔记应用、聊天应用、设置工具。visionOS会运行它们；用户没有理由在visionOS上而非iPad上使用它们。跳过。

开发团队没有visionOS特定的测试条件。 visionOS是装机量最小、模式最脆弱的平台；没有真机就测试Vision目标格外困难，比watchOS的情况更甚。

隐私和在场感顾虑占主导。 健康披露应用。敏感的工作场所工具。visionOS设备会以iPhone不会有的方式在家庭成员之间共享；展示私密信息的应用在那里需要的姿态与iPhone上不同。

Apple TV是焦点引擎

TV应用由Siri Remote的焦点引擎驱动：用户用遥控器移动焦点高亮、按下选择，从不会看到触控交互。tvOS上的SwiftUI通过.focusable(...)修饰符、@FocusState属性包装器以及用于状态绑定的.focused(...)来支持这一点，但每个TV应用都需要从零开始的焦点设计。⁶iPhone的点击和滚动模型无法转译。

支持TV的信号：

应用用于在观看TV的距离上消费内容。 流媒体视频（Apple TV+、Netflix）。照片幻灯片。用户用遥控器控制的家庭游戏应用。用户在沙发上、屏幕在远处、输入稀疏，TV是合适的平台。

应用具有iPhone不具备的”靠后”使用场景。 用户跟随的健身视频。用户在炉灶旁参考的烹饪应用。用户睡觉时听的睡前故事。这些场景由立在咖啡桌上的手机来服务都不算合适。

交互模型适合稀疏的、焦点驱动的导航。 用户每次挑选一项的列表。选项网格。线性的播放流。任何比这更复杂的，多点触控手势、细粒度的文本输入、拖放，都无法在tvOS上工作，意味着这个目标是错的。

不支持TV的信号：

应用需要文本输入。 通过遥控器进行的TV文本输入,是任何Apple平台上最糟糕的输入模型之一。如果应用需要的不只是一个搜索框，跳过TV。

应用价值取决于用户双手得腾出来做其他事情。 健身追踪。健康监测。实时协作。TV是屏幕，不是可穿戴设备。

相对于装机量，维护成本过高。 tvOS相对于iOS的装机量较小。开发成本是真实的（焦点设计、单独的测试、tvOS的App Store审核）。对大多数应用而言，这笔账并不能证明这个席位的合理性。冥想应用只有在使用场景真正回报”我坐在沙发上时让它低亮度地留在屏幕上”模式时,才赢得Apple TV席位；没有这种模式，即便一款计时器清晰地映射到TV的靠后模式，它也不该承担维护账单。

矩阵的实际应用

每个集群应用的实际矩阵：

模式很清晰：每一行都是一次有意的删减,与有意的添加同等重要。Return触达六个平台,因为每一个都通过特定的用户价值测试得到了证明；仅iPhone的应用留在那里,因为别处没有合适的位置。同一套工具链,不同的产品,不同的矩阵。

让矩阵可持续的三项架构决策

三种模式让多平台应用免于在自身重量下崩溃：

共享核心使用#if os(iOS)、#if os(macOS)、#if os(watchOS)（及类似指令）来门控平台特定的表面。⁷核心领域逻辑（数据模型、业务规则、同步）在所有平台上编译。平台特定的UI隐藏在编译时条件之后。SwiftUI的@available(iOS 26.0, macOS 26.0, ...)涵盖操作系统版本差异；那些跨平台真正分歧的表面（没有iPhone等价物的Mac菜单栏、没有iPad等价物的Watch复杂功能）在#if os(...)门控下放入目标特定分组中的各自文件。

跨设备同步通过单一基底进行,按领域选择。 NSUbiquitousKeyValueStore用于跨设备的小型会话级状态（Return用它做跨设备计时器状态）。iCloud Drive JSON文件用于跨进程桥接（Get Bananas配合其MCP服务器使用,在单一真实来源中介绍）。SwiftData用于进程内状态。按领域混合基底没有问题；同一领域使用两种基底就是产生漂移的失败模式。

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

何时增加平台是错误的

三种情形下，更容易的路径是错误的。

团队因为工具链让事情变得简单而添加目标平台。 Xcode的”复制目标”向导让添加Mac或visionOS目标变成四下点击的操作。这四下点击不包括设计审查、可访问性审计、App Store截图制作、持续的发布协调、按平台的测试。从向导发布而没有伴随这些工作的目标,在第一天就是有缺陷的。

团队把目标数量当作地位信号。 “我们发布在五个Apple平台上”在发布推文中听起来很令人印象深刻。发布推文不在用户设备上运行；应用才在。一款两个平台都做到位的应用,胜过一款摊得太薄的五平台应用。

团队低估了持续维护成本。 每个Apple平台每年都会发布操作系统的重大更新。一款五平台应用有五套发布说明需要响应、五套行为变更需要测试、五套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开发的钩子；Live Activities；watchOS运行时契约；SwiftUI内部机制；RealityKit的空间心智模型；SwiftData架构纪律；Liquid Glass模式；多平台发布；我拒绝写什么。中心枢纽位于Apple生态系统系列。要了解更广泛的iOS与AI代理上下文,请参见iOS代理开发指南。

常见问题

我如何决定是否要添加一个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的后台执行模型。手腕放下,系统挂起应用,只有特定的会话类型（WKExtendedRuntimeSession的self-care、mindfulness、physical-therapy、alarm,以及HKWorkoutSession的workout-processing）才能在挂起后继续运行。⁴没有清晰会话类型的应用会产生第二次使用就失效的体验。集群中的watchOS运行时博文详细介绍了该契约。

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

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

参考资料