一條黑邊先被留了下來：傳統 UIKit 專案適配 iPhone Duo 的第一版，是一頁妥協出來的介面

2026 年 10 月 15 日，掘金開發者「健了平_24」發布了一篇關於傳統豎屏 UIKit 專案適配 iPhone Duo 的技術文章，附上一份名為 WaterfallLayoutDemo 的示範專案。文章自己承認「還不完善」，但正是這種第一版的粗糙，透露出摺疊螢幕時代裡，老 App 的介面如何被一步一步重新設計。

先看文中最具體的一個決定：在 info.plist 裡加入 UIRequiresFullScreen。這個設定的效果是，豎屏 App 在內屏橫屏時保持豎屏比例置中顯示，多出來的空間就是兩條黑色邊條。這是所有選項裡最保守的一條路，與之相對的是微博式的做法，先做介面整體拉伸，寧可變形也不留白。作者選了後者，理由寫得很白話：「這總比空出一大塊好」。

這兩種策略的差別，本質上是同一個設計問題：當畫面尺寸不再固定，第一版要優先保住什麼。黑邊保住的是比例與版面結構，拉伸保住的是內容的填充感。作者選拉伸，等於承認第一版的目標是「能用」，而非「好看」。這與我們先前觀察的iPhone Duo 三合一的協調設計正好是同一枚硬幣的兩面：手機端被設計得協調好看的前提，是 App 端先撐住所有場景。

文章列出 iPhone Duo 帶來的全部場景：外屏橫豎、內屏半開橫豎、內屏全開橫豎、內屏左右分屏。對開發者而言，這份清單的意義是宣告兩個昔日的不變量失效：介面尺寸與安全區域。作者用了一句頗有畫面感的話，UIScreen 可以直接拋棄，後文又補了一句「UIScreen 依舊難逃一死」。同一個 API 被判了兩次死刑，可見這次適配動的是地基。

技術細節上，作者的方案類似過去的橫豎屏切換：集中一處監聽裝置方向變動，再通知指定頁面更新版面。UIScreen.main.bounds 換成 view.bounds 或 window.bounds，safeAreaInsets 從固定值變成上下左右都會動態變化。 UIViewController 端，willTransition 能提前拿到新尺寸但拿不到新的安全區域，真正同時知道兩者的位置是 viewDidLayoutSubviews，官方也推薦在這裡適配。UIView 對應的則是 layoutSubviews。

文章也誠實記下了 AI 的極限。Xcode 27.1 以上建構的 App 被強制適配，理論上可以叫 Agent 配合 app-resizability 技能直接改，但老 App 經 AI 改造後「大概率幾乎都重構了」，反而可能引發新 Bug。作者估計，很多頁面需要設計師重新設計，加上測試，真正適配好最快也要一、兩個月。所以第一版先不重構成 iPad 式多欄，先求相容所有場景，之後再逐步替換需要重做的頁面。

這段估算值得單獨看。它說明摺疊螢幕的適配成本，最重的部分落在設計而非工程：程式碼可以整批改，版面卻得逐一重新想。這也與我們之前寫過的iPhone Duo 六成良率的品質語言形成對照：硬體端在良率與品質標準之間掙扎，軟體端則在重構與黑邊之間掙扎，兩邊都在為同一個新形態付出第一代的代價。

收在一個明確的觀點上：這篇文章最有價值的地方，是它把「第一版」當成一個被認真定義的產品階段，而非敷衍的權宜。先拉伸、後重構、黑邊只留給方向相反的場景，這套順序本身就是一份設計決策清單。摺疊螢幕的第一版適配，考驗的從來不是技術上限，而是一個團隊願意在哪裡先妥協、在哪裡堅持不留白。