截至 2026 年 10 月 17 日，Apple 的设计资源页面已列出 iOS 27 与 iPadOS 27 的 Figma UI Kit。结论先定：你可以在 Windows 上用 Figma 完成设计和协作；要构建原生项目、运行模拟器，就需要能运行适配版 Xcode 的 Mac。模拟器也不能替代所有真机测试。
谁该看这篇：
用 Windows 和 Figma 制作 iOS 界面、要把稿件交给 Apple 平台开发者的设计师。
要区分设计稿检查与原生应用验收责任的产品设计师、自由职业者和小团队负责人。
最后更新于 2026 年 10 月 17 日；版本与资源信息核对自 Apple Design Resources、Apple 设计资源更新记录及 Xcode 官方文档。(Apple 设计资源更新记录)
01 先分清 UI Kit、设计稿与应用
Apple 将 iOS 27 与 iPadOS 27 的 UI Kit 作为 Figma 设计资源提供。官方更新记录说明，该资源包含更新后的组件、系统颜色和应用图标。它能帮助你表达设计意图，却不是客户项目的可运行版本。(Apple 设计资源更新记录)
验收时要拆开三个对象：
| 对象 | 你能确认什么 | 不能据此确认什么 |
|---|---|---|
| Figma UI Kit 与设计稿 | 布局、组件选择、颜色、页面状态是否符合设计意图 | 应用实际运行效果、原生交互或构建是否成功 |
| Apple 平台项目与模拟器 | 实际构建结果、导航和弹窗等运行行为、常见屏幕布局 | 所有真实硬件功能、设备性能及最终真机表现 |
| 实体 iPhone 或 iPad | 指定设备上的实际操作、硬件依赖行为与项目要求的真机结果 | 其他未测试设备或系统组合的表现 |
Figma 设计稿不是应用本身。 UI Kit 是用于设计的组件资源；原生项目则是开发者交付给 Xcode 构建的工程。若你只检查画布，就只能签署视觉稿或设计交接，不能把结论写成“原生应用已验收”。
02 Windows 设计师负责视觉稿时
如果你的工作范围只是 Figma 页面设计与协作，Windows 通常足以完成这部分任务。你可以检查组件是否用对、颜色是否符合项目意图、页面与状态是否齐全；这些是设计稿检查，不是 iOS 应用运行验收。
交稿前按页面逐项确认：
- ✅ 标明页面对应的用户任务，以及进入、退出和返回路径。
- ✅ 补齐加载、空内容、错误、禁用、选中等项目需要的状态。
- ✅ 在图层或交接说明中标出使用的 UI Kit 组件及有意修改之处。
- ✅ 标出系统行为待确认项，例如系统弹窗、权限提示、键盘或导航表现。
- ✅ 对照 Apple 的布局与适配指引，检查安全区域、屏幕尺寸变化和文字大小等影响布局的条件。
不要因为画布里的系统控件看起来熟悉，就默认最终实现会自动匹配。项目可能使用自定义组件、不同的系统接口或其他交互路径；需要由开发者确认实际实现。
03 交接给开发团队时
设计师应交付可复核的信息，不只是静态页面。若构建目标、项目版本和运行设备没有约定，开发者可能在不同条件下检查，之后双方很难判断差异是设计问题、实现问题还是环境不一致。
| 交接项 | 交付内容 | 未确认时的风险 |
|---|---|---|
| 页面与状态 | 页面清单、入口与返回关系、关键状态 | 只检查主页面，遗漏边界状态 |
| 交互说明 | 点击、滑动、弹窗关闭和状态变化 | 静态稿被误当成交互规格 |
| 资源与差异 | 图标、图片、字体等文件及自定义组件说明 | 资源替换后出现视觉偏差 |
| 验收范围 | 由谁构建、谁负责模拟器检查、是否安排真机测试 | 责任边界不清，结论无法追溯 |
| 待确认事项 | 系统行为、设备条件与尚未验证的问题 | 未解决项被误记为通过 |
请让团队明确由谁提供可构建的项目、由谁选择 Xcode 运行目标，以及谁负责模拟器和真机测试。Apple 的运行模拟设备与实体设备文档说明，构建和运行需要选择项目的构建方案与运行目标；缺少对应平台支持时，项目无法在该目标上构建运行。
04 产品设计师判断流程是否真的跑通
产品设计师需要关注的不只是控件外观，还包括用户能否完成任务。应打开实际应用检查关键导航、弹窗、滚动和系统组件，并把问题回写到 Figma 或交接记录，避免团队只根据静态稿宣布通过。
可按下面的条件分流：
- 若只需确认布局、颜色、组件表达和设计协作，选 Windows 上的 Figma 流程；不要为静态稿检查额外安排 Mac。
- 若要确认原生项目能否构建，或核对应用实际运行状态，选 Mac 加适配该项目的 Xcode 和 iOS Simulator；没有自有 Mac 时，先安排开发协作者或核验远程环境。
- 若结论依赖真实硬件、实体设备性能或项目指定的真机条件，不要以模拟器结论代替；回退到实体 iPhone 或 iPad 测试，并由负责人留存结果。
这条分支也适用于“没有 Mac 怎么检查”的决策：若项目方已有开发协作者，要求对方按约定运行并记录结果；若你必须亲自查看运行中的应用，再评估远程 Mac。单有 Figma 文件，不足以启动原生项目验收。
05 没有自有 Mac 的自由职业者安排复核
远程 Mac 只解决“在哪里使用 Mac 环境”的问题，不会自动补齐项目、账号、版本或测试设备。安排之前，把工作拆成准备、验证和留档，避免租到环境后才发现无法开始。
✅ 按这个顺序执行：
- 确认任务边界。写清本次要做的是 Figma 视觉检查、构建检查、模拟器检查，还是还包含真机测试。
- 向开发方索取项目。确认拿到的是可打开的 Apple 平台项目，而不只是导出的截图或 Figma 链接。
- 核实 Mac 与 Xcode。将项目要求的 Xcode、macOS 和目标系统版本，与 Apple 当前的Xcode 系统要求表逐项对照；不要只按“Xcode 27”这个名称判断兼容。
- 确认模拟器运行环境。询问相应模拟器运行时是否已安装。Apple 说明，Xcode 可以通过组件设置下载模拟器运行时；安装未完成时，项目无法在该目标上运行。(Xcode 组件安装说明)
- 约定项目与访问方式。事先确认文件如何交接、你通过什么方式访问 Mac、是否需要团队账号或其他权限，以及复核结束后如何取回记录和修改稿。
- 运行关键路径并留证。按已约定的运行目标检查主流程、弹窗、滚动和异常状态，记录运行环境、发现项、截图与责任人。
- 按风险补真机测试。如果要验证依赖实体硬件的功能或发布表现，安排实际设备测试；模拟器结果单独归档，不要混写成真机通过。
具体 Xcode 与系统的支持关系可能随版本更新。开始项目前再次查看官方系统要求与团队锁定的版本，发现不兼容就先调整环境或请开发方接手，而不是把无法启动归为设计验收通过。
06 开发协作者与 QA 需要留下两类结论
开发协作者负责确认项目能否在约定环境构建、运行，并向设计师说明模拟器与真机之间的边界。模拟器适合复核常见界面和流程，但 Apple 指出它不能完整复现实体设备的性能或功能；若功能依赖设备特性，应在实体设备上测试。(Apple 关于模拟器与设备测试的说明)
QA 或项目负责人应按风险指定真机范围。例如，若项目依赖实体硬件能力、真实设备性能，或交付要求明确指定真机验证，就必须在相应实体设备上复核。发布构建也应按项目要求在实际设备上测试。
交付记录至少要把结果分成三栏：
- 设计稿：视觉与组件表达由谁检查，哪些问题已回写。
- 模拟器：使用的项目构建方案、运行目标和检查结果；未运行的项目标为未验证。
- 真机：实际测试的设备与行为、测试负责人，以及尚未覆盖的风险。
⚠️ 模拟器画面接近设计稿，不等于项目在每台 iPhone 或 iPad 上都符合预期。把未测设备、未测硬件行为和未完成的构建明确标为“未验证”，不要用“通过”概括。
在这套分工下，Windows 加 Figma 对纯设计任务更直接；但项目要求原生构建或模拟器复核时，它不能提供相同的 Mac 开发环境。自购 Mac 适合持续、高频使用；请开发协作者复核能省去另行准备环境的步骤，但你会依赖对方的时间。若你只需临时打开项目、检查模拟器结果，远程 Mac 可作为另一种安排，不过仍要提前确认环境、文件交接和访问权限。你可以从 CALMVPS 的远程 Mac 服务说明了解使用方式，再通过方案与价格页面判断是否适合这次任务；不需要亲自运行原生项目时，则不必为验收额外准备 Mac。