截至 2026 年 10 月 10 日，Apple Developer 已列出 iPhone Duo 設計指引，並提供 iOS 與 iPadOS 27 的 Figma UI Kit；這些資源可用來準備設計，但靜態稿不能證明原生應用在不同裝置姿態下運作正確。Apple 設計資源更新 官方設計資源頁
本週建議：先用 Figma 固定版面意圖、狀態與未決問題，再確認開發建置和可用測試環境；只有需要檢查原生應用行為時，才安排 Mac 驗收。不要先假設 iPhone Duo 模擬器已可用。

這篇適合正在設計 iPhone Duo 介面的 UI 設計師，以及要向 Apple 平台開發者交接雙螢幕需求的產品設計師。
如果你以 Windows 為主力設備，想知道哪些工作可在 Figma 完成、哪些需要原生環境驗證，也可依下方流程判斷。

01

動手前先分清楚：你要交付的是稿件、互動說明，還是可執行成果

先把「設計驗收」和「原生驗收」分開。交付一份 Figma 原型，代表團隊可以查看畫面、元件與你記錄的互動預期；它不代表應用程式已在 iPhone Duo 上執行，更不能單靠畫面判定裝置姿態切換時的行為正確。

在開始整理檔案前，先寫下這次交付的驗收目標：

  • 視覺交付：確認畫面層級、字體、間距、元件位置與設計版本。
  • 互動交接：說明點擊、切換姿態、內容延續或重新排列時的預期。
  • 原生應用驗收：確認開發建置能否執行，以及實際裝置或已確認支援的測試環境是否可用。

把這三項分開，可避免設計師把「Figma 中看起來合理」誤記成「原生應用已通過測試」。如果需求只到視覺稿與互動意圖，Windows 上的 Figma 工作不必等到取得 Mac 才能開始。

02

Windows 設計師能用 Figma 準備 iPhone Duo 介面嗎？

可以。你可以在 Windows 上整理頁面、元件、版面說明與互動預期；Figma 的瀏覽器設定若出現載入或操作問題，可先按其瀏覽器設定說明檢查環境。這一步處理的是設計準備，不是 iPhone Duo 原生測試。

官方的 iPhone Duo 設計指引和 Figma UI Kit 可作為佈局起點。下載或套用 UI Kit 後，仍要核對它與專案需求是否相符；資源檔不會自動替你完成合規檢查，也不保證實際執行結果。

使用官方素材前，請一併閱讀 Apple 設計資源的授權條款，並依團隊用途確認可使用範圍。不要把「已使用官方 Kit」當成可省略審核或交付註記的理由。

03

把雙螢幕與裝置姿態整理成可檢查的狀態

iPhone Duo 的設計需要讓開發者理解：畫面在不同姿態下如何調整，而不只是看單一螢幕截圖。建立 Figma 頁面時，至少要把下列狀態分開標示，並依官方設計指引核對實際適用方式：

  • 主要工作畫面：標出核心內容、主要操作與視覺優先順序。
  • 雙螢幕配置：說明內容如何分配、是否延續，以及跨螢幕的操作關係。
  • 姿態改變後的版面：標明哪些區塊重排、縮放、隱藏或保留。
  • 關鍵互動狀態：記錄選取、返回、錯誤或內容更新後，兩個畫面各自應呈現什麼。
  • 未定義狀態：如果設計規格尚未決定，直接標為待確認，不要用靜態稿推測裝置行為。

這不是要求每個畫面都複製成多份。你要提供的是足以讓開發者重建設計意圖的代表性畫面，以及狀態切換的說明。對需要分辨雙螢幕責任的頁面，可在 Figma 加上簡短文字：哪一部分是固定導覽、哪一部分隨姿態變動、哪些內容必須維持連續。

04

交接前把設計決策與開發待辦分開

設計交接的重點，不是把檔案連結丟給開發者，而是讓對方能追溯每個版面決策及尚未確認的問題。建議在 Figma 專案或隨附文件中整理：

  • 代表性畫面與對應的狀態名稱。
  • 主要互動預期，以及狀態切換前後的差異。
  • 尚未決定的規格，例如內容是否跨屏延續。
  • 已確認事項、待開發確認事項，以及需要實際執行才能判斷的項目。
  • 設計檔版本或更新紀錄，避免開發者依舊稿實作。

交接時可用一句話描述每項設計意圖，例如：「姿態改變後，主要操作仍需可見；內容如何分配待開發建置確認。」這比只附截圖更能幫助團隊定位差異。

交付材料 能支持的判斷 不能單獨證明的事
Figma 靜態畫面 視覺層級與版面意圖 原生應用能否正常執行
互動說明與狀態稿 操作預期、狀態切換邏輯 裝置上實際回應是否符合預期
開發建置與測試紀錄 已測環境中的執行結果 未測裝置或未確認支援環境的相容性

因此，截圖可以作為設計證據，但不可標成真機測試證據。若開發者回報問題，請一併記下所用建置、測試條件、發生步驟和預期結果；否則設計端很難判斷是稿件理解落差，還是原生實作問題。

05

原生應用驗收是否需要 Mac？

Figma 設計準備不要求你先有 Mac；原生驗收則要先確認建置與測試環境。如果工作項目涉及 Xcode 或其他 macOS 原生工具鏈，應由開發團隊依官方 Xcode 27.1 發布說明核對當前工具與系統條件。工具版本資訊不等於 iPhone Duo 模擬器或真機已可供測試。

安排 Mac 前，先做這幾項確認：

  1. 開發團隊是否已有可執行的原生應用建置。
  2. Apple 官方資料是否確認目標裝置或對應模擬器可用。
  3. 若使用模擬器，團隊是否已確認它能覆蓋此次要驗收的行為。
  4. 若需真機驗證，是否已確認實際設備與測試安排。
  5. 測試紀錄是否能分清楚環境限制與產品缺陷。

Apple 提供的 iPhone Duo 開發準備資料與 Xcode 模擬器操作講解可供團隊核對準備方式；但操作說明本身不能代替官方對特定設備或模擬器支援狀態的確認。若相關資訊尚未確認，就把該項標成「待驗證」，不要在驗收報告寫成通過。

06

依測試條件決定返修、繼續交付或暫緩

驗收收尾時，把結果分成「已驗證」「待驗證」與「不適用」三類。已在 Figma 核對的視覺稿，記入設計檢查結果；已由可執行建置測試的項目，記錄測試環境與觀察結果；尚未取得目標設備或官方支援資訊的項目，保留限制說明。

用以下條件分流：

  • 若交付只包含視覺稿與互動說明，則完成 Figma 狀態整理和開發交接；原生測試列為後續工作。
  • 若已有可執行建置，且目標測試環境已確認可用，則安排原生複核，記錄重現步驟和結果。
  • 若建置尚未完成，或設備／模擬器支援仍未確認，則不要預約一個未必能完成驗收的環境；先要求開發團隊補齊條件，並將相關結論標為待驗證。
  • 若測試發現稿件與實作不一致，則先對照設計版本、狀態說明與重現步驟，再決定是修稿還是修正實作。

對 Windows 團隊來說，Mac 的價值在於提供需要 macOS 原生工具鏈時的工作環境，而不是替代設計決策，也不能自行證明某項裝置支援。你可以先從 VpsMesh 的 Mac 使用方案了解可選方式；若專案已確認需要 Mac，再查看 Mac mini M4 租用價格說明，並按實際建置、帳號權限與測試條件判斷是否適合。

如果你目前只有 Figma 設計稿，繼續在 Windows 完成交接通常更直接；不需要為尚未確認的模擬器支援先租環境。若專案已進入原生建置階段，但團隊沒有合適的 macOS 工具環境，遠端 Mac 可作為短期驗收選項。相較於臨時借用設備或把測試延後，遠端使用可省去一次性購置硬體與安排實體交接的負擔；但若你需要長期穩定重載工作，或必須連接特定實體周邊，仍應先比較自有 Mac 與遠端環境的限制。租用 VpsMesh 前，先確認你的工具、帳號與測試目標確實適用，再決定是否開始驗收。