01

iPhone Duo Figma 原型交付：先做设计，原生行为另行验收

Apple 于 2026 年 9 月 18 日宣布提供 iPhone Duo 的 Figma 和 Sketch 设计套件；这让你可以先在 Figma 整理界面，但静态稿不能证明原生应用在不同设备姿态下运行正确。(Apple 设计资源更新) 本周建议：先把布局意图、关键状态和未确认项交给开发，再核对开发构建与模拟环境是否可用；确认需要原生工具链后，才安排 Mac 验收。截至 2026 年 10 月 10 日，Apple 已公开 iPhone Duo 设计指导，也在 Xcode 27.1 RC 发布说明中列出对应模拟器运行时；但模拟器仍有已知限制，不能把“能启动”当成“所有功能都能验证”。(iPhone Duo 设计指导)

这篇适合正在用 Figma 设计 iPhone Duo 界面的 UI 设计师，以及要向 Apple 平台开发者说明双屏布局的产品设计师。
如果你在 Windows 上工作，也可以先完成设计准备；是否需要 Mac，取决于你是否要编译、运行或调试原生应用。

02

动手前，先确定这次“验收”究竟要证明什么

“设计稿看起来对”与“应用跑起来没问题”是两种不同结论。开始交付前，把工作拆成以下几类，避免开发团队把静态画面当成设备实测结果：

  • 视觉方案：页面结构、信息层级、控件位置和文案是否明确。
  • 交互说明：点击、返回、状态保留、内容变化等行为是否有可复现的描述。
  • 原生表现：开发构建在目标环境中运行时，界面能否随显示区域变化、避开保留区域，并保持关键操作可用。
  • 设备兼容与功能验证：特定设备、系统、功能或扩展是否能正常工作。此项须由开发者依据当前官方支持信息和可用测试环境确认。

前两项通常可以从 Figma 文件开始整理；后两项需要运行中的应用和对应测试环境。把验收目标写进任务说明，能避免最后才发现团队争论的其实不是同一件事。

03

在 Windows 上准备 Figma 文件，并把设计边界写清楚

如果你已在 Windows 上使用 Figma，可以先完成页面组织、原型连接和交付标注，不必为了设计准备先迁到 Mac。Figma 官方说明支持通过浏览器使用；具体浏览器设置和图形能力要求，以其浏览器配置说明为准。

准备 iPhone Duo 设计稿时，可从 Apple 的设计资源页面获取 iOS 与 iPadOS 27 的 Figma UI Kit，并查看 iPhone Duo 相关设计资源。套件能帮助你使用对应的界面素材和模板，但它只是设计起点，不是原生合规证明，也不会替你验证构建结果。

交付文件建议按页面或用户任务分组，不要只堆放最终截图。每个关键页面至少说明：入口是什么、用户完成什么操作、状态如何变化，以及哪些部分只是视觉示意。开发者如果需要复现问题，应能从标注定位到页面和状态，而不是猜测一张图对应什么情境。

⚠️ Apple 的设计资源许可将资源用途限定在创建用于 Apple 平台软件的界面模型等范围。团队复用或对外分发设计素材前，应先核对设计资源许可条款，不要把 UI Kit 当作可任意转售的素材包。

04

双屏布局检查要覆盖姿态变化，而不只是两张屏幕图

Apple 的 iPhone Duo 设计指导提到设备姿态、双显示屏动态布局、中央折叠区域和竖向工具栏等设计边界；不同状态下可用空间会变化。指导建议界面随可用空间调整，避免把布局绑定到固定屏幕尺寸。

所以，iPhone Duo 双屏布局检查不要只交一张外屏稿和一张内屏稿。要让开发知道界面在状态变化时应如何延续，特别是：

  • 外屏与内屏：内容从单列变成双栏时，信息主次是否清晰？哪些次级内容可以在更大区域展开？
  • 部分折叠：中央折叠区域附近是否会挡住标题、输入框、按钮或需要连续阅读的内容？
  • 控件位置变化：工具栏、标签栏或导航控件改到侧边时，主要操作是否仍容易找到？
  • 状态连续性：切换屏幕或姿态后，表单输入、列表选择和当前任务是否保留？
  • 狭窄空间与分屏：内容变窄时，文字、卡片、弹层和按钮如何收缩或重排？

以上检查点不是要求你为每种姿态另画一套互不相关的页面。以可适配布局处理不同空间，并维持功能与元素状态的一致性；你的稿件要把“哪些内容随空间变化”说清楚，避免设计稿暗示固定位置，而开发实现必须临时推翻布局假设。

05

交给开发时，让每个待办都能被复现

实际协作中最常见的问题不是文件打不开，而是“看见了异常，却说不清在哪种状态出现”。交付包可按下面的顺序准备：

  • 整理代表性页面，并为每个页面写明用户从哪里进入、目标是什么。
  • 标出外屏、内屏和部分折叠下的预期变化；特别注明不可被折叠区域遮挡的关键内容。
  • 为关键控件补上默认、选中、禁用、加载、错误等相关状态；只列项目实际存在的状态，不必机械补齐。
  • 在原型中连接核心操作路径，并用文字说明原型没有模拟的原生行为。
  • 单独建立“待开发确认”区域，记录尚未确认的设备支持、系统行为、权限或测试条件。
  • 给问题反馈留出复现信息：页面名称、触发动作、预期结果、实际结果，以及截图或录屏的来源。

设计交接的责任边界也要写明：设计师定义预期界面和交互意图；开发团队确认实现方案、官方支持和构建条件；实际设备或模拟环境中的结果由负责测试的人记录。截图可以作为观察材料，但如果截图来自静态稿，就不能标注成“原生设备已通过”。

你也可以把 Apple 的 iPhone Duo 设计指导附到交付说明中，方便开发逐项核对保留区域、动态布局和控件安排。

06

原生验收前，先核实开发构建与工具链

截至 2026 年 10 月 10 日，Apple 的 Xcode 27.1 RC发布说明已列出 iPhone Duo 模拟器运行时，并说明该版本要求运行在 macOS Tahoe 26.6 或更新版本的 Mac 上。发布说明同时列出已知限制：模拟器中的待机功能不可用，大多数应用扩展无法运行和调试。因而，模拟器可用于特定布局观察，却不能自动替代真机或覆盖全部扩展场景。(Xcode 27.1 发布说明)

原生复核按这套流程走，能避免先租机器、后发现缺少工程或账号权限：

  • 确认对象：请开发提供可运行的项目或开发构建，并明确本次要验证的是布局、交互、扩展还是设备行为。
  • 核对官方支持：查看 Apple 的iPhone Duo 开发准备资料，逐项确认目标系统、模拟器运行时和已知限制。官方页面会更新，旧截图或旧项目经验不能替代当前说明。
  • 确认工具链条件：检查团队是否已有符合版本要求的 Mac、Xcode、项目依赖、开发者账号和必要证书。缺一项，就先解决构建条件，而不是直接开始设计验收。
  • 先跑可验证项：在已确认可用的模拟器中观察布局、姿态变化和基础交互，并记录应用版本、环境、操作路径及限制。
  • 补做受限场景：如果要验证模拟器不支持的扩展行为或必须依赖真实设备的表现，安排对应的实体设备测试；不要用模拟器结果代签。
  • 按证据结案：把每项结论标成“已验证”“待验证”或“不适用”，并附上证据来源。无法获得目标环境时，应明确写出验收限制，不要把空白项写成通过。

Apple 的 Xcode 技术讲解展示了在 Device Hub 中启动 iPhone Duo 模拟器、切换设备姿态的操作路径。项目需要这类原生检查时，先确认团队能获得合适的 Xcode 和 macOS 环境，再决定由本地设备还是远程 Mac 承担。(Xcode 模拟器操作讲解)

07

按条件选择验收方式，再决定是否需要远程 Mac

当前条件 更合适的下一步 交付结论边界
只有 Figma 稿，尚无可运行构建 完成布局说明、状态标注和开发交接 只验设计与交互说明，不宣称原生通过
已有构建，且目标模拟器和所需功能可用 由开发者在已核实的 Xcode 环境中进行模拟器复核 结论限于实际运行过的项目和场景
验收涉及模拟器限制的扩展或真机专属行为 先确认对应设备和测试安排，再进行补测 模拟器结果不能替代缺失的设备证据
团队需要 Xcode，但没有合适的本地 Mac 比较购买、借用或按项目租用 Mac 的可行性 先核实系统版本、账号权限和访问方式
项目长期持续运行，或依赖实体接口与稳定专用工作站 优先评估自有 Mac 或固定测试设备 临时租赁未必适合持续重负载或物理接口依赖

决策条件：

  • 若你目前只有 Figma 原型，选择设计交接；不要因为项目名称里有 iPhone Duo 就先租 Mac。
  • 若开发已给出可运行构建，且 Apple 官方资料确认了所需的模拟环境与功能，才进入模拟器复核。
  • 若必须使用 Xcode，而团队暂时没有符合系统要求的 Mac，可比较本地 Mac 与Mac mini 租赁方案；若只在短期项目中临时使用，租赁可避免为一次验收购置整机，但仍要先核对环境、权限和实际任务是否匹配。
  • 若任务需要真机专属功能、长期稳定高负载或专用物理接口，远程 Mac 并不能取代相应设备或固定工作站。

设计阶段使用 Windows 的优势是无需迁移现有 Figma 流程；限制是它不能代替 macOS 上的 Xcode 构建、运行和调试。Mac 则能承接这些原生工具链工作，但要考虑环境准备、远程连接和团队权限；如果只是静态稿检查，增加 Mac 环节反而会带来不必要的成本。对于确实要打开 macOS 原生工具的临时项目，先查阅 VpsMesh 的 Mac 租赁说明，确认当前系统、访问方式和项目条件适用后再决定。长期固定使用、需要物理设备或持续高负载的团队，则应如实比较自购 Mac 与专用测试设备，不必为了短期便利强行租赁。