畫面一變寬，現有 App 就可能出現留白、元件擠壓或表單狀態遺失。
最快的解法：先不要按預購消息估價或重寫；本週先盤點頁面、尺寸變化處理與測試範圍，再核實 iPhone Duo 的官方規格和開發介面。
這篇適合正在評估 iPhone Duo 支援計畫的 iOS 開發者，協助你確認哪些版面與互動程式碼要檢查。
若你負責排期或預算，可用文中的工作拆分建立可追溯估算；產品經理則可據此判斷測試資源是否要列入發布計畫。
最後更新於 2026 年 10 月；核對 Apple Newsroom 公告與 Apple Developer 文件。Apple 已發布 iPhone Duo 相關公告，但公告不等於所有團隊所需的尺寸行為、SDK 支援與介面細節都已確認。請以Apple 的預購公告及裝置介紹中明確列出的內容為準，不要把未確認資訊當成估算前提。
先用現有版面判斷摺疊螢幕適配範圍
適配通常不等於重寫 App。若現有頁面已採用自適應版面，主要工作較可能落在可用區域改變時的版面調整、互動狀態保存及回歸測試，而非從頭建立整套介面。Apple 的版面設計指南可作為評估原則；它不能替你判斷專案中哪些畫面會出問題，這部分仍要看實際程式碼與產品流程。
有幾類情況會拉高工作量：
- 固定尺寸或位置假設：用固定寬高、手動計算座標，或假設內容永遠放得下的頁面，在可用區域變動時更容易溢出、重疊或留下不合理空白。
- 尺寸變化時沒有重新配置：若畫面只在載入時決定版面，沒有處理 trait 或 scene 幾何資訊的改變，轉換尺寸後可能仍沿用舊配置。可對照 Apple 的trait 環境文件與視窗場景幾何資訊檢查程式邏輯。
- 互動狀態依賴畫面重建：表單、導覽堆疊、選取狀態或編輯內容若未妥善保存，使用者離開頁面、切換場景或版面重新配置後，就可能需要重做操作。Apple 提供了介面狀態保存說明，可用來核對 UIKit 專案的狀態處理。
- 元件或測試依賴未確認：第三方元件可能把尺寸假設藏在內部；若自動化測試只驗證單一版面狀態，也無法代表尺寸變化後的流程安全。
因此，iPhone Duo 目前能否按特定尺寸、系統行為或 SDK 介面估工，應以官方已公布資料及實際可用開發文件為界。資料未確認時，將相關工作列為待核實假設，而不是寫成確定需求。
按四類程式碼與專案證據評分
App 開發者先按頁面清單分類，不必先數程式碼行數。改動量較受以下因素影響：頁面複雜度、固定尺寸寫法、元件相依性，以及測試能否重現尺寸和狀態變化。UIKit 團隊可檢查 trait 與 safe area；SwiftUI 團隊則應確認版面是否依實際容器尺寸安排，例如參照 Apple 的GeometryReader 文件與safe area 佈局說明。
下表是供專案內部使用的風險評分方法，不是產業平均值或工時基準。每個維度都要附上頁面、程式碼或測試紀錄，才可用來推估工作。
| 評估維度 | 低風險 | 中風險 | 高風險 | 要找的專案證據 |
|---|---|---|---|---|
| 頁面與版面複雜度 | 頁面少、內容流動 | 有多欄或條件式區塊 | 多層容器、複合工作區 | 頁面清單、版面結構、設計稿 |
| 固定尺寸寫法 | 約束或彈性容器為主 | 少數頁面含固定值 | 核心流程大量依賴固定位置 | 程式碼搜尋結果、畫面截圖 |
| 尺寸與狀態處理 | 有明確更新及保存邏輯 | 規則分散或不完整 | 版面只初始化一次、狀態易丟失 | trait、scene、狀態保存程式碼 |
| 元件相依性 | 自有元件且可調整 | 部分依賴外部元件 | 關鍵元件行為不明或無替代方案 | 套件清單、元件文件、測試結果 |
| 自動化測試覆蓋 | 核心流程可重跑 | 只有部分頁面涵蓋 | 主要靠人工且案例不完整 | 測試案例、失敗紀錄、覆蓋範圍 |
把每項評為低、中或高後，先處理「高風險且涉及核心流程」的頁面，再排中風險項目。高風險不自動等於重寫；它代表你需要更明確的驗證，並可能預留局部重構。不要把頁面數直接乘上一個通用工時，因為同樣一頁，靜態資訊畫面與含表單、導覽及暫存狀態的畫面不是同一種工作量。
第二步：把改造和測試分開估價
可信的預算應由團隊自己的工作量和人力單價計算。按階段拆分，可避免只報「改版面」卻漏算審查、互動修正與回歸測試。
| 預算階段 | 要完成的工作 | 可核對的估算依據 | 費用算法 |
|---|---|---|---|
| 盤點與規格核實 | 整理頁面、檢查官方規格及介面支援 | 頁面清單、待確認項目、程式碼審查紀錄 | 盤點工作量 × 團隊人力單價 |
| 版面調整 | 修正約束、尺寸斷點、safe area 與容器配置 | 受影響頁面、設計稿、修改範圍 | 版面工作量 × 團隊人力單價 |
| 互動與狀態處理 | 驗證導覽、輸入、場景切換及狀態復原 | 核心流程、狀態轉移、缺陷清單 | 互動工作量 × 團隊人力單價 |
| 回歸與發布驗證 | 執行必測流程、修正缺陷、確認發布條件 | 測試矩陣、執行紀錄、待修問題 | 測試及修正工作量 × 相應人力單價 |
| 可選測試環境 | 評估遠端建置或測試環境需求 | 團隊現有設備、存取方式、實際方案資料 | 環境費用另列，不併入適配人力 |
這個算法不預設通用價格，也不把未經盤點的工時包裝成報價。你需要先由實際負責人估出各階段工作量，再套用團隊的完全成本人力單價；若頁面範圍、裝置行為或第三方元件狀況尚未確認，就把該部分標成暫估，並註明待補資料。
測試不能只算「開發完成後跑一次」。首先要驗證官方文件確認的介面與行為，再以核心使用流程查出尺寸調整是否破壞版面或狀態。核心流程通常包括登入、主要任務完成、表單輸入、頁面前後切換；產品若含媒體、複雜列表或長時間編輯，再按功能加入對應情境。Apple 的場景幾何文件可作為 UIKit 場景尺寸資訊的核對入口，但不能代替實機或可用測試環境中的驗證。
提醒：在官方尺寸與系統行為尚未核實前，不要把某個假設的展開方式或畫面尺寸寫進固定測試規格。先記錄假設、來源與負責確認的人；條件改變時，再更新測試矩陣及預算。
常見問題：把改碼量和預算問題拆開
iPhone Duo 的程式碼改動要從哪裡開始？
先找出最常使用、最複雜及最依賴固定尺寸的頁面，檢查版面計算、尺寸變化處理、safe area、導覽和狀態保存。UIKit 可從 trait 與 scene 相關處理追查；SwiftUI 則檢查容器是否依可用空間配置。每一項改動都記錄頁面和程式碼證據，方便估算時複查。
摺疊螢幕適配是否代表要重寫現有 App？
不代表。自適應版面完整、元件可調整而且狀態保存可靠時，先評估局部修正和回歸測試即可。若核心流程建立在固定尺寸上、關鍵元件無法配合，或架構令每次尺寸調整都牽動大量頁面，才把局部重構與維持現狀的成本放在一起比較。是否重寫應由專案證據決定，不由預購消息決定。
開發成本估算要包含哪些項目？
至少分開計算盤點、版面改造、互動與狀態處理、測試及發布驗證。各項工時由團隊按頁面複雜度、程式碼狀況和測試案例實際填入，再乘以團隊人力單價。若遠端建置或測試環境另有成本，獨立列出；沒有可核實的環境資料，就不要填入推測金額。
哪些頁面與互動需要列入回歸測試？
先列出會影響主要任務的頁面，再驗證尺寸改變、頁面切換、前後景往返、鍵盤與表單輸入、內容保存及重新進入。媒體播放、複雜列表或長時間編輯等情境，則按產品功能增列。測試紀錄應能連回頁面、裝置和系統條件；尚未確認的裝置行為要標為待核實，而非當成既定規格。
本週完成預算評審前檢查
- [ ] 從產品流程整理頁面清單，標出核心流程、複雜版面與低使用率頁面。
- [ ] 搜尋固定寬高、手動座標及只在初始化時配置版面的程式碼，記錄涉及的畫面。
- [ ] 核對 UIKit trait、scene 與 safe area，或 SwiftUI 容器尺寸處理，標出未驗證的假設。
- [ ] 確認第三方元件版本、可取得的行為說明及目前測試結果；無法確認的相依性列入風險。
- [ ] 將尺寸變化、主要流程、輸入、狀態保存與場景切換納入測試矩陣，再按產品功能加入擴展案例。
- [ ] 分別填入盤點、版面、互動、測試及發布驗證的工作量和團隊人力單價。
- [ ] 把遠端建置或測試環境成本獨立列示；若沒有可核實的方案資料，先留待確認，不要混入適配人力。
若你的現行方案是共用本機設備或沿用既有測試機，可能遇到排程互相等待、可測裝置不足，以及環境重現不易等限制；臨時採用遠端 Mac 測試則仍需評估連線延遲、權限與資料保護，不一定適合長期高負載或依賴實體介面的工作。VPSSpark 的 Mac 租用可作為短期建置或回歸測試環境的候選方案，但應先按可核實的配置與費用另列環境成本，不要拿它替代適配工程報價。你可先到VPSSpark 幫助中心查找可確認的服務資訊；若需釐清環境方案與支援流程，也可參考VPSSpark 的服務協助資訊，再用頁面清單、程式碼風險和測試矩陣完成團隊估算。
以 VPSSpark 雲端 Mac，推進摺疊螢幕適配與 iOS 開發
透過遠端 Mac 執行 iOS 建置、簽署與測試工作，讓團隊更有效率地驗證版面調整。
可依專案需要選擇 Mac mini M4 配置，適合短期評估或持續開發使用。