先看一個關鍵資料點： Apple 的 App Store Connect 截圖規格會按顯示目標、裝置類別與方向區分提交要求，並非所有 Simulator 輸出都能直接上傳。Apple 官方截圖規格是驗收基準。
因此，少量頁面、少量語言且很少更新時，手動截圖通常更省事；一旦需要多語言、多裝置或頻繁改版，就應改用 fastlane snapshot。 遠端 Mac 可以承載重複執行的截圖工作，但正確順序是先固定測試資料、語言和 Simulator 環境，再逐步開啟並行與自動上傳。
這篇適合三類讀者：
- 需要為多個 App Store 本地化版本重複製作截圖的獨立開發者。
- 沒有常駐 Mac、但要執行 Xcode UI Tests 和 iOS Simulator 的 Windows／Linux 開發者。
- 想把截圖生成納入版本發布流程的小型 App 團隊。
[ SECTION_01 ] 先計算截圖矩陣，再決定是否自動化
App Store 截圖自動化的起點不是安裝指令，而是先列出畫面組合。矩陣至少應拆成四個維度：
- 頁面狀態：首次啟動、登入後、訂閱狀態、空資料、主要功能完成畫面。
- 語言與地區：介面語言、區域格式、貨幣、日期和動態文字。
- 裝置與方向：iPhone、iPad、直向、橫向，以及 Apple 要求的顯示目標。
- 更新頻率：一次性上架、每月改版，或每週都要重新產生素材。
若只是一次產生少量畫面，手動操作的準備成本較低。若相同流程要在多個語言和裝置重複執行，人工截圖容易出現檔名錯位、漏圖和登入狀態不同等問題，此時才值得建立 snapshot 流程。
| 工作類型 | 建議方式 | 主要風險 | 驗收證據 |
|---|---|---|---|
| 少量頁面、單一語言、偶爾更新 | 手動截圖 | 忘記重置狀態 | 人工逐張檢查 |
| 固定頁面、單一裝置 | snapshot 最小鏈路 | UI 選取器失效 | 圖片、檔名、測試報告 |
| 多語言、多裝置 | snapshot 矩陣 | 語言與資料不一致 | 語言目錄及逐組抽樣 |
| 頻繁改版、無人值守 | snapshot 加 CI 工作 | 遠端工作階段或 Runtime 失敗 | 日誌、HTML 彙總、可重跑記錄 |
| 素材需要品牌外框 | snapshot 加 frameit | 原始畫面被錯誤裝飾 | 原圖與宣傳圖分開保存 |
| 已完成驗收的資產提交 | 手動或 API 上傳 | 錯誤批量覆蓋 | App Store Connect 處理狀態 |
這個判斷也能避免一個常見誤區：截圖捕獲、圖片裝飾、資產上傳和 App 審核不是同一件事。snapshot 只負責按照測試流程取得原始畫面；frameit 類工具處理裝置外框或宣傳版式；上傳工具則負責提交資產。每一層都要獨立驗證。
[ SECTION_02 ] 用單一語言和單一裝置建立可重複基線
第一次執行不應直接建立完整矩陣。先選一個語言、一個裝置和兩至三個穩定頁面，確認測試能從乾淨狀態完成。
1. 建立專用 UI Test Target
在 Xcode 建立專用的 XCTest UI Tests Target，例如使用占位名稱 AppScreenshotUITests。不要直接把截圖步驟塞進一般回歸測試，否則產品測試和素材生成會互相影響。
將測試使用的 Scheme 設為共享，並確認測試 Target、App Target 和測試主程式的 Bundle ID 都使用脫敏占位值，例如：
APP_BUNDLE_ID=com.example.placeholder
TEST_SCHEME=PlaceholderApp
Apple 的 XCUIElementQuery 文件說明了 UI 元件查詢的基本行為。實作時應優先使用穩定的 accessibility identifier，不要依賴會因語言而變動的顯示文字。
2. 固定啟動狀態
為截圖流程準備專用啟動參數，例如：
--screenshot-mode
--reset-test-data
--locale=zh-Hant
--subscription=active
--feature-demo=on
參數名稱只是占位示例，實際名稱應由 App 自行定義。重點是每次啟動都能控制登入態、訂閱態、空資料與功能開關。
測試資料可放在本地 fixture，也可使用專用測試服務。不要讓畫面依賴真實使用者歷史、隨機推薦或不穩定的第三方 API。否則同一個測試即使程式碼沒有變更，截圖也可能出現不同內容。
注意： 登入成功不等於畫面可重現。測試帳戶還要固定權限、訂閱狀態、資料數量和伺服器回應；否則多語言比對時，很難判斷差異來自翻譯還是資料。
3. 讓 snapshot 驅動 XCTest
fastlane 官方的 iOS 截圖流程文件和 snapshot 參數文件可用來核對參數、語言、裝置和輸出設定。
設定中應保留清晰的語言與裝置清單，並將輸出資料夾固定到專案外可收集的位置。示意結構如下：
fastlane/
Snapshotfile
screenshots/
zh-Hant/
en-US/
metadata/
指令與 Scheme 使用占位值：
bundle exec fastlane snapshot \
--scheme "PlaceholderApp" \
--output_directory "./fastlane/screenshots"
若專案採用 Gemfile，應鎖定工具版本並在遠端 Mac 上使用相同依賴。這不是為了追求某個特定版本，而是避免本地與遠端對參數或輸出格式的理解不同。
4. 把「成功」定義為三層證據
第一次跑通時，不要只看 XCTest 顯示通過。至少要確認：
- 預期語言目錄確實產生圖片。
- 檔名與測試執行順序一致，沒有漏掉中間畫面。
- snapshot 產生的 HTML 或測試彙總結果能指出每個裝置組合的狀態。
Apple 的 Xcode 測試結果說明可用於理解測試結果與失敗記錄。截圖工作還要另外保存原始圖片和執行日誌，方便日後重跑。
[ SECTION_03 ] 把語言、內容和裝置組合拆開管理
多語言截圖最容易出錯的地方，是只切換系統語言，卻沒有同步控制區域格式和測試內容。繁體中文介面可能仍顯示英文測試資料，英文介面也可能載入不適合的日期格式。
建議將以下設定分開管理：
- 語言：例如
zh-Hant、en-US，對應 App 的本地化資源。 - 區域：控制日期、數字、貨幣和排序格式。
- 測試資料：控制名稱長度、商品標題、帳戶狀態和資料筆數。
- 功能開關：控制新功能、付費牆、教學頁和錯誤提示是否出現。
同一個截圖節點在不同語言中，應檢查四件事：文字是否完整、按鈕是否被截斷、版面是否因字串變長而重疊，以及畫面是否停在載入中。這些檢查不能由檔案存在與否取代。
| 驗收維度 | 要檢查的內容 | 發現問題時的處理 |
|---|---|---|
| 目錄 | 語言代碼與 App Store Connect 目標一致 | 修正配置，不要手動改檔名掩蓋問題 |
| 文案 | 標題、按鈕、價格和日期符合該地區 | 回到 fixture 或本地化資源修正 |
| 狀態 | 登入、訂閱、空資料和功能開關可重現 | 重新設定啟動參數 |
| 版面 | 長文字沒有截斷、重疊或超出安全區 | 更新 UI 或為該語言建立專用流程 |
| 圖片 | 方向、檔案格式、透明通道及順序正確 | 按 Apple 規格重新輸出 |
| 上傳 | 顯示目標、語言和處理狀態正確 | 先小批量提交，再擴大範圍 |
[ SECTION_04 ] 按 Apple 顯示目標控制裝置矩陣
不應機械式遍歷所有 Simulator。先查看 Apple 當前的 截圖規格與顯示目標要求，再決定哪些裝置類別真的需要產出。
Apple 的規格頁列出不同顯示目標的尺寸要求。例如，頁面中會區分 6.7 吋 iPhone 類別、6.5 吋 iPhone 類別和 12.9 吋 iPad 類別；這些尺寸與支援狀態應以該頁當前內容為準，不應把舊文章中的裝置名稱直接複製到流程內。
決策時可採用以下方法：
- 先選能代表主要 UI 版面的 iPhone 直向組合。
- App 若支援 iPad，再獨立驗證 iPad 版面，不要假設 iPhone 會自動適配。
- App 有橫向流程時，將橫向視為另一組測試，不要在同一個測試中隨意旋轉。
- 只有在規格、產品需求或實際版面需要時，才增加其他裝置。
- 把裝置組合寫進配置，避免開發者每次以個人記憶選擇 Simulator。
App Store Connect 可能對某些素材提供自動縮放，但這不代表所有畫面都適合交給平台縮放。若關鍵文字、表格或特定比例 UI 在不同尺寸下會移位，就應為目標顯示尺寸提供定製截圖，並在上傳前逐組查看。
[ SECTION_05 ] 遠端 Mac 執行時先求穩定，再談並行
在遠端 Mac 上執行 iOS 截圖任務，核心依賴包括 Xcode、對應的 Simulator Runtime、足夠的硬碟空間、可持續的使用者工作階段，以及能取回檔案的連線方式。遠端桌面只是觀察工具，不應成為整個任務的必要條件。
這套遠端 Mac 流程建議按以下步驟落地：
- 確認環境：檢查 Xcode 能開啟專案，目標 Simulator Runtime 已安裝，Scheme 能單獨執行。
- 固定工作目錄：為每次執行建立清楚的輸出資料夾，避免新舊圖片混在一起。
- 串行跑基線：先只執行一個語言和一個裝置，保存測試報告、原始截圖與終端機日誌。
- 增加語言：確認同一節點在不同語言中內容完整，再加入下一個語言。
- 增加裝置：先加入 iPhone，再按實際需求加入 iPad 或橫向組合。
- 觀察資源壓力：從日誌、Simulator 啟動失敗和連線狀況判斷是否適合並行，不要一開始就同時啟動多個模擬器。
- 設計恢復路徑：為每個語言／裝置組合保留獨立輸出，失敗時只重跑該組，不要覆蓋全部結果。
- 取回結果：將圖片、HTML 彙總、測試報告和執行日誌一併下載，不能只取回圖片。
同時執行多個 iOS Simulator 容易失敗，通常不是 snapshot 本身「不能並行」，而是多項資源和狀態互相爭用：記憶體不足、Runtime 啟動衝突、共享測試帳戶被改寫、遠端桌面畫面負載增加，或某個 UI Test 沒有正確清理狀態。fastlane 文件中的並行與裝置參數應先在小矩陣驗證，再逐步調整。
經驗提醒： 遠端工作階段中斷後，先查看輸出目錄和測試報告，再決定是否重跑。直接全量重跑可能把原本成功的結果覆蓋，增加排錯範圍。
[ SECTION_06 ] FAQ：把四個常見執行疑問先處理
fastlane snapshot 怎樣自動產生多語言 App Store 截圖？
先在 snapshot 設定中列出語言與裝置組合，再讓專用 UI Test Target 以固定啟動參數載入測試資料。每個語言環境都應重新執行相同的導覽流程，最後按語言目錄、檔名順序與畫面內容逐項驗收，不能只依賴測試通過狀態。
沒有本地 Mac，仍然可以批量產生 iOS 應用程式截圖嗎？
可以，前提是遠端 Mac 具備相容的 Xcode、Simulator Runtime、測試專案與穩定使用者工作階段。Windows 或 Linux 電腦可透過遠端桌面或 SSH 發起工作，但必須先確認模擬器能正常啟動、檔案可以取回，並預留斷線後查閱日誌及重跑失敗組合的方式。
fastlane snapshot 如何固定登入狀態和測試資料？
不要使用開發者個人帳戶的即時資料。測試應準備專用測試帳戶、可重置的本地資料或固定 API 回應，並以啟動參數控制登入態、訂閱態、空資料畫面及功能開關。這樣每次執行都從相同狀態開始，較容易判斷是 UI 變更還是資料波動造成差異。
遠端 Mac 同時運行多個 iOS 模擬器為什麼容易失敗？
每個模擬器都會同時消耗記憶體、儲存空間、CPU 與圖形資源，遠端桌面還會增加顯示與連線負擔。多個測試程序也可能爭用相同的測試資料、連接埠或登入服務。較穩妥的做法是先串行建立基線，再按實際日誌與資源壓力逐步增加並行量。
[ SECTION_07 ] 將原始截圖、宣傳圖和上傳分成三個階段
snapshot 輸出的原始畫面，應先保存一份不加裝飾的版本。若需要裝置外框、背景或宣傳文字，再使用 frameit 官方流程製作另一份資產。原始圖和營銷圖不能混用，否則出現版面問題時很難追溯。
上傳前可按以下順序驗收：
- 比對語言目錄與 App Store Connect 的本地化項目。
- 確認每個檔案屬於正確的顯示目標和方向。
- 檢查圖片順序是否對應產品希望展示的導覽順序。
- 檢查透明通道、檔案格式、尺寸和錯誤頁面。
- 先抽樣人工查看每個語言及每種裝置，再提交完整批次。
- 依照 App Store Connect 上傳說明確認處理狀態，而不是看到上傳完成就視為發布完成。
- 保存本次配置、提交內容和生成結果，讓下一次改版可以重現。
App Store 截圖自動化最重要的品質指標，不是一次生成多少檔案，而是能否知道每個檔案為何生成、屬於哪個版本，以及失敗後能否只重跑必要組合。批量處理會放大錯誤，也會放大正確流程的價值，所以驗收必須先於上傳。
[ SECTION_08 ] 如何選擇短期遠端執行或常駐環境
如果只是某次上架前製作一組截圖，購買或維護本地 Mac 可能造成閒置成本，Windows／Linux 本機也無法直接執行 Xcode UI Tests 和 iOS Simulator。繼續依賴人工截圖，則會遇到狀態不一致、語言漏圖、裝置規格錯配和斷線後無法恢復等問題。
若需要在每次版本發布時重複產出，NOVAKVM 的遠端 Mac 可作為獨立的 macOS 執行環境，讓開發者按需使用 Xcode、Simulator 與測試工具。需要先了解服務入口與可用環境時，可查看 NOVAKVM 的遠端 Mac 服務頁面；再按語言數量、裝置矩陣和更新頻率判斷短期使用或常駐執行。若已確定要使用遠端環境，也可進一步參考 NOVAKVM 遠端 Mac 方案。
但若團隊需要長期、穩定且高負載地持續執行，或必須接觸實體 iPhone、USB 配件和本地硬體除錯，自購 Mac 仍可能更合適。遠端方案的優勢是免除硬體採購、閒置和維護；代價則是要管理連線、工作階段、檔案取回和遠端環境重置。完成最小鏈路後再作選擇，通常比先買設備或盲目開啟並行更穩妥。
對需要臨時生成素材、測試多個本地化版本，或把截圖任務納入發布流程的開發者而言，先在 NOVAKVM 建立一套可重跑的遠端 Mac 環境，再依實際矩陣決定使用週期，能避開本地 Mac 不足、人工截圖反覆返工，以及 Windows／Linux 無法直接運行 Xcode 的長期限制。
常見問題
fastlane snapshot 怎樣自動產生多語言 App Store 截圖？
先在 snapshot 設定中列出語言與裝置組合，再讓專用 UI Test Target 以固定啟動參數載入測試資料。每個語言環境都應重新執行相同的導覽流程，最後按語言目錄、檔名順序與畫面內容逐項驗收，不能只依賴測試通過狀態。
沒有本地 Mac，仍然可以批量產生 iOS 應用程式截圖嗎？
可以，前提是遠端 Mac 具備相容的 Xcode、Simulator Runtime、測試專案與穩定使用者工作階段。Windows 或 Linux 電腦可透過遠端桌面或 SSH 發起工作，但必須先確認模擬器能正常啟動、檔案可以取回，並預留斷線後查閱日誌及重跑失敗組合的方式。
fastlane snapshot 如何固定登入狀態和測試資料？
不要使用開發者個人帳戶的即時資料。測試應準備專用測試帳戶、可重置的本地資料或固定 API 回應，並以啟動參數控制登入態、訂閱態、空資料畫面及功能開關。這樣每次執行都從相同狀態開始，較容易判斷是 UI 變更還是資料波動造成差異。
遠端 Mac 同時運行多個 iOS 模擬器為什麼容易失敗？
每個模擬器都會同時消耗記憶體、儲存空間、CPU 與圖形資源，遠端桌面還會增加顯示與連線負擔。多個測試程序也可能爭用相同的測試資料、連接埠或登入服務。較穩妥的做法是先串行建立基線，再按實際日誌與資源壓力逐步增加並行量。