Apple 在 Xcode 27.2 發布說明中確認：Device Hub 的 VoiceOver、Accessibility Inspector 等無障礙工具無法傳達 iPhone Duo 的螢幕內容。這是工具讀取限制，不應直接等同於應用缺陷；驗收時要拆開視覺版面、無障礙語義與實際操作，並以可核驗的替代證據補齊。

時間點：截至 2026 年 11 月 14 日，此限制以 Apple 的 Xcode 27.2 發布說明為依據；下一版 Xcode 或相關文件更新後，應重新核對。
本週建議動作：先在團隊 CI 報告中加入「未驗證／工具受限」狀態，再為關鍵操作安排不依賴該 Device Hub 讀取能力的補驗收。

企業 iOS QA 負責人：確認版面與無障礙測試各自的覆蓋邊界。
CI 平台工程師：判斷哪些檢查可自動化，哪些要另行驗收。
發布負責人：建立限制情境下仍可追溯的放行依據。

01

Xcode 27.2 iPhone Duo 無障礙測試的判讀邊界

Apple 記錄的是 Device Hub 中特定無障礙工具無法傳達 iPhone Duo 的螢幕內容；這不是「iPhone Duo 所有無障礙測試都不可用」的結論。也不能因此判定所有應用都存在缺陷，或推定後續 Xcode 版本仍有同一限制。Apple 的 Device Hub 裝置管理說明可用來核對該工具的裝置管理範圍；具體限制則應以發布說明為準。

先區分以下狀況，避免把失敗訊號合併成單一判斷：

  • 工具無法讀取：檢查沒有取得裝置螢幕內容，結果是未驗證，不是應用通過，也不是應用失敗。
  • 版面呈現異常：截圖或人工觀察顯示元件被遮擋、錯位或無法辨識，應按視覺缺陷處理。
  • 無障礙語義或操作異常：標籤、角色、提示或焦點移動不符合預期，應另按應用無障礙缺陷調查。

這些狀況可以同時發生，但不能互相代替。報告必須寫清楚測試目標、工具、觀察內容與證據來源。

02

姿態與版面問題的驗收方式

外螢幕、內螢幕，以及展開或折疊狀態可能呈現不同的內容配置；方向變更或非對稱安全區域也可能影響可用版面。Apple 的 iPhone Duo 設計指南可供核對姿態、方向和安全區域相關設計要求。這些屬於版面驗收依據，不能當作 VoiceOver 或其他無障礙語義已通過的證明。

建議按以下流程留下可重現的視覺證據：

  • 確認測試目標及當下姿態、方向，記下外螢幕或內螢幕等狀態。
  • 依測試案例操作到目標畫面，保存截圖並記錄進入畫面的步驟。
  • 對照預期內容位置、可見範圍及安全區域，描述實際差異，不只寫「畫面異常」。
  • 在另一個相關姿態或方向重複觀察；若差異只在某一狀態出現，將它連同該狀態一起報告。
  • 將結果標為「視覺檢查」，不要由截圖推論輔助功能標籤或焦點順序正確。

若問題是畫面擠壓或元件位置不合預期，應建立版面問題；若問題是工具沒有傳回螢幕內容，則應另記為工具限制。兩種證據分開保存，後續才有辦法判斷是應用修正、驗收補做，還是工具支援需要更新。

03

無障礙語義與操作行為的分層核驗

工具無法讀取畫面，不代表應用端的無障礙資訊一定不存在。開發與 QA 可檢查互動控件是否有合適的可存取標籤、角色和提示，並觀察焦點能否按預期順序移動。Apple 的 VoiceOver 應用程式支援說明可作為應用側實作依據；應用程式無障礙測試指南則可協助規劃檢查方式。

需要把三種記錄分開：

  • 應用屬性：標籤、角色、提示等設定是否符合設計意圖。
  • 執行時行為：焦點順序及關鍵操作是否能按預期完成。
  • 工具讀取結果：Device Hub 是否實際傳達裝置螢幕內容。

前兩類結果不能寫成第三類已成功。若透過其他路徑核對應用屬性或操作行為，報告要標明所用方法與環境，並附上可供複查的結果。Apple 的應用程式無障礙審核說明亦可用來規劃額外審核；審核項目與實際操作驗收仍應分開描述。

04

模擬器與實機證據的適用範圍

模擬器適合觀察可重現的版面狀態、執行自動化案例，或檢查可取得的應用資訊；但模擬器通過，不能證明實際裝置上的所有輔助功能互動都已驗收。Apple 說明可在模擬器或裝置上建置及執行應用程式，團隊仍需按目標裝置與測試內容判斷證據是否適用。

可按以下條件選擇補驗收路徑：

  • 若只需確認姿態下的視覺版面，使用截圖與重現步驟留存結果；若狀態無法重現或截圖不足以說明問題，回到目標裝置補做觀察。
  • 若需確認應用提供的無障礙屬性，採用團隊可核驗的應用側檢查，並保留屬性結果；若無法取得可靠證據，標為未驗證，不以版面截圖代替。
  • 若需確認 VoiceOver 或焦點操作流程，安排符合支援設備與關鍵任務的實際互動補測；若測試路徑不能涵蓋該互動，就不能宣稱此項已通過。
  • 若 Device Hub 仍無法傳達螢幕內容，把工具受限寫入測試結果，另附補測方法及其限制；不要把「未執行」改寫成「通過」。

常見驗收問題

Device Hub 為何無法檢查 iPhone Duo 的無障礙內容？
應先對照 Apple 的 Xcode 27.2 發布說明：其中記載的是 Device Hub 內 VoiceOver、Accessibility Inspector 等工具無法傳達該裝置的螢幕內容。這是工具能力範圍的說明，不足以推論其他測試路徑也失效。報告應記錄版本、檢查類型及實際輸出。

VoiceOver 和 Accessibility Inspector 不能讀取時，怎樣補驗收？
把版面觀察、應用側屬性核對與實際操作分開安排。視覺檢查保存截圖及姿態；語義核對記錄標籤、角色和提示；操作測試則保存關鍵步驟及結果。每種方法要標示它能證明什麼、不能證明什麼，避免把替代測試誤記為 Device Hub 已讀取成功。

怎樣分辨工具限制與應用缺陷？
若問題是 Device Hub 沒有傳達螢幕內容，先記為工具受限或未驗證；若其他檢查能指出標籤缺失、焦點順序不符預期或版面遮擋，才依該項證據建立應用缺陷。要能重現問題，並保留測試環境、操作步驟及觀察結果，避免只根據單一工具的空白輸出下結論。

這些結果能直接作為 CI 放行證據嗎？
不能單靠 Device Hub 的受限結果放行，也不能由此判定應用不合格。CI 應明確列出未執行或未驗證項目，連結替代證據，並由 QA、無障礙負責人與發布負責人依團隊既定規則確認。必要檢查缺少證據時，應按內部放行條件處理，而不是標記為通過。

05

Mac CI 報告與發布放行條件

Mac CI 報告應能讓接手的人看懂「測了什麼、在哪裡測、結果如何」，而不是只提供一個整體通過或失敗狀態。至少記錄 Xcode 版本、測試目標、模擬器或實機環境、檢查類型、結果狀態，以及日誌、截圖或其他可核驗證據的位置。版本與環境資訊可從建置流程記錄；Apple 的在模擬器或裝置上執行應用程式說明可協助核對測試目標與執行方式。

若團隊正在評估 CI 節點的承載方式，可先參考香港遠端 Mac 環境的選擇資訊，再依實際工具鏈、測試流程與權限要求確認是否適用。

以下紀錄格式只是一個欄位範例，不代表任何實測結果：

Xcode: <實際版本>
Target: <測試目標>
Environment: <模擬器或實機及姿態>
Check: <視覺／語義／操作／Device Hub>
Status: <通過／失敗／未驗證／工具受限>
Evidence: <日誌、截圖或測試紀錄位置>

發布前由 QA、無障礙負責人與發布負責人確認未覆蓋項目、替代驗收證據及風險接受責任。Apple 的發布說明界定已知工具限制，並不構成 Apple 強制的團隊放行流程；是否可發布，仍應由團隊按預先訂定的關鍵檢查與風險規則決定。若 Apple 更新發布說明或工具行為改變，應重新核對並評估是否調整驗收流程。

核驗項目 可留下的證據 不可據此推論
視覺版面 姿態、方向、截圖與重現步驟 螢幕閱讀器語義已正確
應用無障礙屬性 標籤、角色、提示及焦點相關核驗結果 Device Hub 已成功讀取螢幕
實際操作 關鍵任務的操作紀錄與測試環境 未測試的裝置或路徑也已通過
Device Hub 讀取 工具版本、檢查項目及輸出狀態 工具受限就代表應用缺陷或測試全數不可用

自購 Mac 可提供團隊直接管理的硬體，但會帶來採購與折舊安排、日常維護，以及閒置容量如何利用等考量；共用實體主機也要處理遠端使用與排程協調。若需求是短期建立 Mac CI 或驗收環境，遠端 Mac 租用可作為另一種評估方向，但仍須先確認實際測試流程、工具支援與團隊權限要求。可先依遠端 Mac 環境資訊核對方案，再用自己的關鍵應用路徑驗證是否符合需要。

NodeMini 適合納入需要臨時 Mac 算力或測試環境的比較；若工作負載長期穩定且持續繁重，或必須直接使用特定實體介面，則應一併評估自購設備與維運條件。先建立可追溯的無障礙驗收紀錄，再檢查 Mac CI 能否穩定執行團隊所需的 Xcode 與測試流程，才有依據選擇承載方式。