Apple 公告要求自 2027 年 4 月起適用 iPhone Duo 截圖要求，詳見官方公告。因此，你現在應盤點應用程式、語言版本與截圖產出流程，將素材檢查納入發布驗收；不必只因這項要求更換 CI 平台或 Mac 節點。
企業 iOS 發布負責人：協調產品頁面素材與版本提交。
CI 平台負責人：把素材完整性與發布證據接入自動化。
多應用團隊 IT 負責人：評估素材資產對既有發布治理的影響。
最後更新於 2026 年 10 月 13 日；時程與規格核對自 App Store Connect 發布說明、Apple 截圖規格及截圖上傳說明。
公告時程：先納入計畫，不等於現在已生效
Apple 已公布 iPhone Duo 截圖要求，適用時間是 2027 年 4 月起，不是現在。將它排入 2026 年的發布準備工作，是為了讓素材製作和責任分工有緩衝；不要在內部文件中把未到的適用時間寫成當前提交限制。時程應以Apple 公告為準。
這項要求談的是產品頁面的截圖素材，不等同於裝置相容性測試，也不能推導出必須添購或租用另一台 Mac。前者要確認頁面呈現的素材符合規格；後者要驗證應用程式在目標裝置或執行環境中的行為。兩者可能共用發布節點，但驗收證據和負責人不應混為一談。
你的第一個里程碑應是建立「待準備」清單，而不是改造建置基礎設施。把官方要求的適用範圍、預定生效時間和團隊內部截止日分欄記錄，避免日後把內部提前準備日期誤當成 Apple 的政策日期。
素材盤點：逐一補齊應用與語言版本
在發布計畫建立時，先整理現有產品頁面素材。至少記錄應用程式識別資訊、平台版本、語言版本、素材存放位置、負責人和最近一次審核結果。若團隊管理多個應用程式，請以每個產品頁面為單位盤點，不要只統計共用的素材資料夾。
再為每個項目標記狀態，例如「已有可用素材」、「需重新產出」、「規格待核對」或「負責人未確認」。這樣可以把缺口交給明確的產品、QA 或發布負責人，而不是等到上傳時才追問素材來源。另將團隊內部希望完成的日期標為計畫，不要與 Apple 的適用時間混寫。
盤點時要留意幾類常見隱性成本：
- 語言版本容易漏列：主語言素材齊全，不代表其他產品頁面也已準備。
- 素材版本未必對應目前應用：舊截圖可能展示已移除的功能或過期介面。
- 權責分散會拖慢提交：產品、設計、QA 與發布工程師若各自保存檔案，最後很難確認哪份已核准。
- 自動檢查不能取代審核：檔案尺寸符合規格，不代表畫面準確反映實際體驗。
規格核對：官方尺寸與畫面內容分開確認
素材製作前，先從App Store Connect 截圖規格確認目標裝置適用的像素尺寸、方向、檔案格式及可展示範圍。不要以舊版內部文件或其他裝置的素材尺寸代替最新規格；Apple 的規格頁才是核對依據。
檔案格式也應明確驗證。Apple 的上傳說明列出可接受的格式，包括 PNG 和 JPEG；同一份文件亦說明產品頁面的素材上傳方式。將格式與尺寸檢查寫成可重複執行的驗證，而不是只靠檔名或人工目測判斷。上傳說明亦指出，每個本地化產品頁面最多可上傳 10 張截圖；這是頁面上限，不是每個團隊都必須交滿的數量。
畫面內容則要另行審查。核對畫面是否來自實際應用體驗、是否清楚展示對應功能，以及是否與目前版本一致。Apple 的截圖審核指南涉及截圖與應用程式內容的呈現要求；尺寸檢查通過，不代表畫面內容自然符合審核要求。也不要假定模擬器輸出或某個 Xcode 工具能自動完成全部製作、選圖和審核工作。
提醒：把「裝置相容性測試通過」與「產品頁面截圖已核准」分成兩項驗收。截圖檔案存在，不代表 App Store Connect 已接受素材。
產出流程：先指定責任，再決定自動化範圍
在產出素材之前，明確指定由產品團隊、QA 或發布流程負責提交候選檔案。每份素材應保留原始檔、語言版本、對應應用程式版本、產出來源及審核狀態。若需要重新拍攝或修圖，保留能追溯到實際介面的依據，避免把純行銷設計稿誤當成裝置截圖。
若以腳本或 Xcode 工具輔助產出，先在團隊現有環境做一次可重複性驗證。Apple 的 Xcode 27.1 發行說明可用於核對該版本的官方工具資訊，但不要僅因版本名稱就假定它能自動產出所有語言與所有產品頁面所需素材。把實際驗證過的步驟、輸入和輸出記下來，再決定是否納入正式流程。
CI 門禁：自動驗完整性，人工確認呈現
企業 iOS CI 可以負責重複、明確的檔案檢查：例如依應用程式與語言讀取素材清單，確認必要檔案存在且可開啟，再按當前官方規格核對尺寸與格式。檢查結果應附在相應建置或發布紀錄，包含缺少的語言、失敗原因、檢查版本和處理責任人。
不要讓檢查腳本只回報「成功」或「失敗」。對發布工程師而言，能定位到哪個應用、哪個語言版本缺什麼，才足以支援修正與稽核。若有多個應用共用同一流程，也應讓每個產品頁面有各自的素材清單，避免一個應用的檔案被誤用到另一個頁面。
決策條件：
- 若素材清單能按應用程式與語言版本維護，且檢查可產生可追溯報告，就將完整性檢查放入既有 CI 或發布門禁。
- 若規格仍在變動，或腳本無法可靠判斷素材適用範圍，就先輸出人工覆核清單，不要讓未驗證的自動化結果直接放行。
- 若問題只是素材管理、責任分工或檢查邏輯不足，先修正發布流程；只有測試證明現有 Mac 環境在工作負載、存取控制或穩定性上不符需求時，才評估更換承載方式。
CI 通過只表示團隊的內部檢查完成。素材仍須依照App Store Connect 上傳流程提交，並由負責人確認頁面預覽和最終狀態；不要把自動化報告寫成 Apple 已接受素材的證明。
試行驗收：用一個產品頁面走完提交閉環
挑選一款具代表性的應用程式，完成從盤點、素材產出、規格檢查、上傳到頁面預覽的全流程。每個環節記錄負責人、檔案版本、結果和失敗原因。這次試行的目標不是追求自動化比例，而是確認團隊能否重現流程、辨識錯誤並安全回退。
出現問題時，按失敗類型更新操作清單：規格錯誤回到官方規格頁核對；素材缺漏回到應用與語言清單指定負責人；畫面或審核問題交由產品和發布負責人覆核；上傳操作問題則依 App Store Connect 說明重新確認。完成試行後，再決定是否擴展到其他應用，而非一次把未驗證規則推入所有產品的發布門禁。
常見問題：提交時間與既有環境
iPhone Duo 截圖要求何時適用？
Apple 公告所列時間為 2027 年 4 月起。在此之前，應把準備工作安排進發布計畫，但不要把它描述為目前已生效的提交條件。若公告或適用範圍更新，應重新核對 Apple 的發布說明，再更新團隊的內部截止日與檢查清單。
App Store Connect 截圖規格應如何核對？
直接查閱 Apple 最新的截圖規格頁，按目標裝置確認像素尺寸、方向、檔案格式與產品頁面的適用範圍。規格可能因裝置類別而異，不要複製其他版本的尺寸表。完成檔案檢查後，仍須檢視截圖呈現內容，因為技術規格合格與內容審核是不同的判斷。
企業 iOS CI 怎樣判斷素材是否齊全？
以應用程式和語言版本建立素材清單，讓 CI 驗證檔案是否存在、可讀並符合已確認的規格，同時輸出具體缺漏。將報告關聯到建置版本，方便發布負責人追蹤。這項檢查能提高內部一致性，但不代表上傳結果已獲 Apple 接受。
這項要求會迫使團隊更換 CI 或 Mac 嗎？
不會僅因截圖要求就必須更換。先在既有流程驗證素材產出、檢查與提交步驟；若實測發現目前環境在併發能力、權限隔離或穩定運作方面無法承載，再根據工作負載評估新環境。不要把產品頁面素材準備問題誤判為建置節點規格問題。
發布環境評估：先驗證需求，再選承載方式
若現有流程依賴開發者各自的 Mac，常見代價是環境差異、素材散落與責任追蹤困難；若把所有工作塞進單一共享節點，則可能遇到排程競爭、權限混用和故障影響面過大的問題。自購設備適合長期穩定且有明確維運責任的負載，但要計入採購、折舊、維護和閒置成本。遠端 Mac 則可作為按需求配置的 macOS 工作環境選項，不過仍須驗證存取方式、團隊權限、資料保留和與既有 CI 的整合方式。
若你要先評估遠端環境能否承載發布工作，可從 VMSPIN 的服務資訊了解服務形式，並按實際需求核對方案與計價資訊。截圖要求本身不構成更換環境的理由；只有當你需要隔離的 macOS 工作區，或現有設備確實無法穩定承載建置與驗證任務時，才值得把租用方案納入比較。若團隊已有足夠的自有 Mac、需要固定實體介面，或長期高負載下自建更符合總成本，維持自有環境可能更合適。