iPhone Duo 上市前 iOS App 要重新適配嗎？2026 尺寸、橫豎屏、多視窗與 Xcode 測試成本

今天是 2026 年 10 月 15 日。Apple 產品頁寫著預購從 10 月 16 日太平洋時間凌晨 5 點開始，10 月 23 日起開賣。10 月 5 日的開發者新聞已經允許用 Xcode 27.1 重新編譯並提交；從 2027 年 4 月起，新提交還要帶上 iPhone Duo 截圖。能啟動只說明舊二進位還在。它不說明內屏鋪滿，不說明橫豎屏走對了分支，也不說明分屏時主按鈕還在安全區裡。10 月 13 日那篇把改造工期和 Mac 買斷放在一起算。這篇只回答上市前的問題：要不要改程式碼，以及這一輪測試該花多少。

為什麼能開啟還不等於重新適配

舊判斷和新判斷卡在同一句使用者反饋上。舊判斷是「模擬器裡能啟動，上市後再看差評」。新判斷先看佈局還在讀哪一個事實：整塊螢幕、裝置方向，還是當前這一個視窗。Apple 的準備頁寫得很直：用 iOS 27 SDK 及之後構建的 App，會在 Duo 摺疊時改變尺寸。寫死的螢幕尺寸、固定方向和裝置假設，會把佈局拉變形、裁切或放錯位置。

同一份原始碼在三檔 SDK 上長得不一樣，這是上市前的第一刀，不是設計偏好。iOS 26 SDK 或更早能跑，展開後視窗居中、四周留白，合蓋後內容偏在狀態列和相機左側。iOS 27 SDK 會鋪滿內屏的大部分，仍避開右側狀態列。iOS 27.1 SDK 及之後才是最佳化態：內容用滿顯示區域，工具欄和標籤欄豎在狀態列下方。只換商店截圖、二進位仍是舊 SDK 的團隊，使用者開啟內屏看到的是一塊留白。留白不會被理解成「我們下週再適配」。

第二刀是視窗不等於螢幕，方向不等於形狀。準備頁要求每次尺寸變化都重新讀：在 viewIsAppearing 裡讀一次不夠，因為摺疊發生在會話中途。UIKit 把依賴尺寸的佈局放進 layoutSubviews 或 viewDidLayoutSubviews，需要在尺寸變化時做事就用 viewWillTransition(to:with:)。SwiftUI 用 GeometryReader 或 onGeometryChange。縮放從 trait collection 取，不要從 UIScreen.main.scale 取。雙屏裝置上的 main screen 語義含糊，Apple 說它會在未來版本廢棄。

第三刀才是測試機器。Xcode 27.1 裡的 iPhone Duo 模擬器、Device Hub 底部的開合旋轉，以及 macOS 27 上 iPhone 映象的極端拉伸，都綁在 Mac 上。Windows 沒有這條鏈路。團隊打包機怎麼選，見 Xcode Cloud 與遠端 Mac 對比。Xcode Cloud 能編包，替代不了你坐在 Device Hub 前把合蓋、半折、展開各轉一次，再把分屏從左邊拖到右邊。

摺疊屏尺寸、橫豎屏和多視窗怎麼分類

把「支援 iPhone Duo」寫成一個里程碑，上市前的排期一定漂。按使用者真正會撞上的行為分成四道門。缺一道，你就會把「能編譯」寫成「已適配」。

尺寸：兩塊屏，加上一個會變的視窗

規格頁把數字寫死了，佈局程式碼不該跟著寫死。外屏是 5.4 英寸 Super Retina XDR，解析度 1398×2034，460 ppi。合蓋機身高 117.8 毫米、寬 84.1 毫米、厚 11.3 毫米。內屏是 7.6 英寸摺疊 Super Retina XDR，解析度 1878×2670，430 ppi，帶奈米紋理。展開後高仍是 117.8 毫米，寬 164.6 毫米，厚 5.2 毫米，重量 254 克。Apple 寫明兩塊屏長寬比一致，內容按比例縮放；按標準矩形測量大約是 5.36 英寸和 7.58 英寸，實際可視區域更小，圓角在矩形裡面。

size class 才是佈局該讀的檔。外屏和其他 iPhone 一樣：豎持是垂直 regular、水平 compact，橫持兩邊都是 compact。內屏水平和垂直都是 regular，側欄有地方放。視窗還可以再小。分屏、半折、映象拉伸都會讓視窗不等於整塊屏。所以規格頁上的畫素是量級，不是常量。縮放用 traitCollection.displayScale 或 SwiftUI 的 displayScale。不要把 1398 或 1878 寫進 ==。

還有兩個容易和「螢幕尺寸」攪在一起的系統行為。圓角用 iOS 26 的 Concentricity：SwiftUI 用 ConcentricRectangle，UIKit 用 UICornerConfiguration。摺痕和相機用預留區，不靠你自己量中縫。SwiftUI 從幾何代理取 ReservedRegion，UIKit 用 UIViewReservedRegion。鉸鏈角度是另一條通道：onHingeChange 和 UIHingeInteraction 給出 closed、partially open、fully open，以及連續角度。Apple 說角度適合做動效，佈局走 arrangement 和預留區。用角度去改 frame，開賣第一週就會在半折上抖。

橫豎屏：外屏聽話，內屏不聽話

準備頁的 Tech Talk 把方向說成兩句。外屏的介面方向和其他 iPhone 一樣，Duo 也是補上橫屏的機會，因為有人會把合蓋的手機像帳篷一樣橫放。內屏不遵守你在 Info 裡宣告的支援方向。和 idiom 一樣，不要用方向做佈局分支。要知道是不是比高更寬，就比較你實際拿到的寬和高：檢視控制器裡用 view.bounds，檢視裡用 superview.bounds，SwiftUI 用 GeometryReader 的尺寸。

要搜掉的屬性是 UIDevice.current.orientation、statusBarOrientation，以及 interfaceOrientation，包括 windowScene.effectiveGeometry.interfaceOrientation。人機介面指南還補了一句連續體驗：橫放時控制元件留在側面，保持同一條垂直高度，而不是把手機橫過來就整頁重排。標準系統元件會自己這樣做。你自己畫的欄不會。

UIRequiresFullScreen 仍然有效，但開合時 App 還是會改尺寸。另一句更容易誤讀：Duo 尊重你宣告的支援方向，可是內屏上的 App 仍會縮放，分屏裡也一樣。所以「我鎖了豎屏，內屏就不會變寬」不成立。安全區經常不對稱。橫屏和分屏裡，豎排按鈕可以出現在左側。用左邊 inset 乘二去推算寬度，會在另一側把按鈕推出螢幕。每一邊單獨減。

多視窗：分屏是預設，第二扇窗不是

多視窗 Tech Talk 的原話是：所有 App 都參與 Duo 上的多工，兩個 App 可以並排。已經為 iPad 或 iPhone 映象做過尺寸變化的，起點更好。還有一種把影片和 App 疊在一起的新佈局，處理方式和分屏相同，仍然讀 size class 和場景幾何，不要為它再寫一套「這是影片」的分支。

Duo 是第一臺支援同一 App 多個介面例項的 iPhone。iPad 上能開新視窗的，這裡也能。差別只有一條：外屏不能建立新視窗，這個行為留給內屏。請求新場景必須處理失敗。用 UIWindowSceneActivationAction，它會在新視窗不可用時自己隱藏，而不是留一個點了就報錯的按鈕。場景配件是第三條路，讓補充介面出現在另一塊屏上。相機的 CameraCaptureAccessory 把額外介面放在外屏，主介面留在內屏全屏，並且要有正在進行的相機會話。合蓋後配件不可用，按鈕要用 onAvailabilityChange 關掉。這是相機 App 的加分項。分屏不是加分項，是所有 App 的預設。

import SwiftUI

struct LaunchCheck: View {
    @Environment(\.horizontalSizeClass) private var widthClass

    var body: some View {
        GeometryReader { proxy in
            let wider = proxy.size.width > proxy.size.height
            Root(regularWidth: widthClass == .regular, widerThanTall: wider)
        }
        .onHingeChange { _, context in
            guard let hinge = context.hinge, hinge.status == .partiallyOpen else { return }
            // hinge.angle drives an effect. Do not lay out from the angle.
            playBend(hinge.angle)
        }
    }
}

這段不是工程模板。它只固定三件事：內屏 regular 寬時可以出側欄，外屏 compact 時收回；橫豎看當前視窗誰更長，不看方向；鉸鏈角度只在半折時推動效，佈局仍走 size class 和 bounds。第二個視窗的按鈕交給會自動隱藏的啟用動作，不要在外屏上留一個永遠可點的「新視窗」。

核心對比：尺寸、方向、視窗和測試成本

真正差異在於程式碼還假不假設「手機只有一塊屏、一個方向、一個視窗」，而不是設計師願不願意做摺疊動效。下面兩張表用同一套列。測試費用是本站定價頁上 M4 16GB 與 24GB 的美元標價：日租 20.2 與 40.2，周租 54.5 與 108.5，月租 100.9 與 200.9。人日不在這篇折成美元，工期檔位和買斷比較在 10 月 13 日的適配成本裡。

把日租乘開，測試成本的結論和改造成本是同一句算術。16GB 的 20.2×5 = 101.0，已經等於月租 100.9。24GB 的 40.2×5 = 201.0，對上月租 200.9。周租 54.5×2 = 109.0，仍略高於一個月的 16GB。所以「先按天試試」只在你確信一到兩天能把矩陣跑完時成立。App Resizability 在第二天掃出一串方向判斷或 UIScreen.main，計費週期就該改成月。第八天付的是週期，不是測試。

矩陣本身可以列成格子，而不是一段「測一下摺疊」。三檔 SDK 各看一眼：留白、避開右側狀態列，還是全屏豎欄。然後在 27.1 的模擬器裡，合蓋、半折、展開各轉一次。內屏上用底部的 Home 指示條把 App 拖到左邊，再拖到右邊，確認豎欄換邊之後主按鈕還在。內屏請求第二個場景；外屏確認啟用動作消失，或請求失敗被你接住。macOS 27 的映象拉伸是加項，用來看比 Duo 更寬或更窄的視窗，不是開賣前的必選項。截圖在主路徑不留白之後再換。提交 Duo 截圖會在產品頁上出現最佳化徽章。2027 年 4 月起新提交必須帶這些截圖，那是商店截止日，不是 10 月 23 日的佈局截止日。

場景怎麼選

真機單獨放一行。鉸鏈手感和模擬器做不到的項需要一臺機器，標價以你下單時的 Apple 商店頁面為準，不要把那一行攤進每一張 Xcode 工單。每人一臺 Duo 不會讓 UIScreen.main 消失，也不會讓外屏突然可以建立新視窗。

推薦組合

A — 獨立開發者，佈局已經跟著尺寸走： Xcode 27.1，本機或一天遠端節點。讓編碼助手跑「get my app ready for iPhone Duo」，或在終端執行 xcrun agent skills export 交給別的代理。掃描是空的，再進 Device Hub：合蓋、半折、展開，各轉一次，再把分屏拖到左右。外屏點一次「新視窗」，確認入口消失。商店截圖用 App Store Connect 的預覽看 Duo。這一輪不必為了測試去買機器。節點月費見 定價頁。

B — 小團隊，方向和自定義欄還在： 第一週只做掃描和螢幕單例，用周租或直接月租，不要日租滾到第七天。第二週把方向分支改成寬高比較，安全區四邊分開寫。第三週把分屏左右各留一張圖，第二場景的失敗路徑寫進迴歸。CI 仍走現有打包機；需要人盯著開合的那次，用同一臺遠端 Mac。24GB 月租 200.9 美元，只在你要並行 Duo 和其他模擬器時才上。五個 40.2 已經等於這一檔月租。

C — 要在開賣當週提交： 今天是 10 月 15 日，預購明天開始，開賣 10 月 23 日。能承諾的是 27.1 下主路徑不留白、豎欄不擋主按鈕、分屏換邊後按鈕還在、外屏不會冒出無效的新視窗。做不到的鉸鏈動效和相機配件不要寫進商店文案。開通見 租用頁。系統版本和賬號走 幫助中心，不要假設映象裡已經預裝 Xcode 27.1。

常見誤區

1. 把能啟動寫成已適配。 iOS 26 SDK 的內屏是居中留白。使用者不會把空邊讀成「適配中」。
2. 把規格頁的 1398 或 1878 寫進常量。 那是畫素量級。視窗在分屏和半折時更小，縮放也不該手寫。
3. 用方向判斷內屏橫豎。 內屏不遵守支援方向。橫豎拿當前視窗的寬高比。
4. 以為 UIRequiresFullScreen 關掉了分屏和開合。 鍵仍然有效，開合時尺寸還是會變；宣告的方向也擋不住內屏縮放。
5. 外屏上留一個永遠可點的新視窗。 新視窗只在內屏。失敗不處理，就會在合蓋時彈錯誤。
6. 用鉸鏈角度做佈局。 角度適合動效。佈局用 size class、預留區和 arrangement。
7. 日租付滿一週。 16GB 五個工作日已經等於月租。第八天是在為計費週期付錢。

落地步驟：7 步

1. 用同一套原始碼對上你能裝的 SDK，先記錄是留白、避讓右側狀態列，還是全屏垂直欄。目標鎖定 27.1。
2. 全域性搜尋 UIScreen.main、UIDevice.current.orientation、statusBarOrientation、interfaceOrientation、userInterfaceIdiom，以及 844、1398、1878 這類尺寸常量。
3. 在 Xcode 裡讓編碼助手跑 App Resizability，或執行 xcrun agent skills export。技能找得到大部分，找不到的用上面的清單補。
4. 開啟 Device Hub 的 iPhone Duo。合蓋、半折、展開各轉一次。再用 Home 指示條把內屏上的 App 拖到左邊和右邊。主路徑每格留一張圖。
5. 內屏請求第二個場景，確認成功或失敗都被接住。外屏確認 UIWindowSceneActivationAction 自己隱藏。
6. 看豎欄是否擋住主按鈕，左右 inset 是否被寫成相等，全幅圖的主體還在不在，半折時預留區有沒有壓住控制元件。鉸鏈角度只檢查動效，不檢查佈局。
7. 選計費週期：一到兩天用日租；掃描已經變髒就改月租。下單前在節點上跑 sw_vers 和 xcodebuild -version。主路徑乾淨之後，再換 Duo 截圖，用 Connect 的預覽看，不要用別的 iPhone 畫布硬縮放。

FAQ

舊 App 不改程式碼，iPhone Duo 上市當天能開啟嗎？

能開啟。用 iOS 26 SDK 或更早構建時，展開後視窗居中留白，合蓋後內容偏在狀態列和相機左側。能跑不等於適配完成。要鋪滿並使用垂直欄，需要 iOS 27.1 SDK。分屏和第二視窗也不會因為「能開啟」就自動正確。

橫屏只在 Info 裡宣告，內屏會遵守嗎？

外屏會遵守你宣告的支援方向，帳篷姿態值得單獨看一眼。內屏不遵守，分屏裡 App 仍會縮放。UIRequiresFullScreen 擋不住開合帶來的尺寸變化。佈局比較當前視窗的寬和高。

多視窗是可選項嗎？

分屏不是可選項。Apple 寫明所有 App 都會並排，影片和 App 疊放也走同一套 size class。新視窗只能在內屏建立。外屏上的入口應使用會自動隱藏的 UIWindowSceneActivationAction。相機外屏配件是加分項，要求內屏全屏並且相機會話正在進行。

只有模擬器，測試成本怎麼算？

佈局主路徑夠。Apple 把 Xcode 27.1 裡的 iPhone Duo 模擬器寫成完整體驗的最佳測試方式。M4 16GB 日租 20.2 美元，五個工作日等於月租 100.9 美元。掃描在第二天變髒，就不要把日租付到第八天。24GB 是 40.2 美元一天、200.9 美元一月，五個日租同樣對齊月租。鉸鏈手感仍要真機，那一行不要攤進模擬器工單。

沒有 Mac，上市前還能測嗎？

不能在 Windows 上跑 Xcode 27.1。先確認節點 macOS 能裝你鎖定的 Xcode，系統要求以 Apple 的 Xcode 系統要求為準。映象拉伸那一項，準備頁寫的是 macOS 27。遠端節點從 租用頁開通，價格以 定價頁為準。

總結

iPhone Duo 10 月 23 日開賣。重新適配的門檻不是「能不能開啟」。先看尺寸是不是還在讀整塊螢幕，方向是不是還在決定內屏，新視窗是不是在外屏上仍可點；這三道門都乾淨，測試成本就是一輪模擬器矩陣，五個日租等於一個月就改月租。 已經自適應的小 App 用本機或短租。方向、畫素和單視窗假設還在的，用月租把迴歸留住。截圖徽章解決不了留白。遠端節點從 租用頁 和 定價頁 檢視，賬戶和系統版本走 幫助中心。

延伸閱讀

• 改造工期和 Mac 買斷怎麼比：10 月 13 日的適配成本 →
• 團隊 iOS CI/CD：Xcode Cloud 與遠端 Mac 打包機對比 →
• 名稱還沒落地時的釋出日期追蹤 →