為 iPhone Duo 做設計：什麼會移動、什麼會分割、什麼保持不動

為 iPhone Duo 做設計需要什麼？ 需要的是兩套版面配置，而不是每種姿勢一套：「為外螢幕準備一套 compact width 版面配置，為內螢幕準備一套 regular width 版面配置，你就具備了應付所有姿勢的基礎」，而 Apple 自己的建議是「把 App 設計成可以自由改變尺寸」。(4:32)¹² 在這個基礎之上，還有指南與三場搭配的 Tech Talk 所描述的四種模式：控制項移到螢幕側邊，並維持由上而下的順序；除非刻意做成滿版，否則內容會相對這些控制項產生偏移；互動元素會從摺痕處位移開，而捲動內容不會；還有一種新的容器 arrangement，會依規則把兩個視圖分割或疊放。後兩者背後的 API 由這幾場 Tech Talk 說明，arrangement 則隨 iOS 27.1 登場。³

10 月 26 日更新：iPhone Duo 於 10 月 23 日（星期五）上架門市，搭載 iOS 27.1，Apple 的安全性更新頁面只為 iPhone Duo 列出這個版本；iOS 27.2 則於 10 月 26 日為「iPhone 11 and later」推出，這是 Apple 為這次更新列出的裝置範圍。Apple Newsroom 10 月 22 日那篇介紹為這支手機打造之 App 的報導，把設計指南重新讀成了使用成果：「有了 Split View，使用者第一次能在 iPhone 上並排開啟兩個 App」，並點名了它所推崇的 App，從 Netflix、Microsoft Word 到 Fantastical、Things 與 Sky Guide。自本文上次更新以來，我沒有重讀指南或那三場 Tech Talk 來確認是否有變動；當天的各個組建請見 iOS 27.2 發行說明那篇文章。⁷

Apple 在主題演講當天下午，把 Designing for iPhone Duo 發布到 Human Interface Guidelines 中，同時推出三場面向設計的 Tech Talk：「Design for iPhone Duo」「Strike a pose with adaptive layouts on iPhone Duo」與「Raise the bar with iPhone Duo」。¹²³⁴ 本站的開發者視角文章算的是點數與 SDK 規則。這一篇談的則是指南要求的設計判斷，引用 Apple 自己的原話並標出各場 Tech Talk 的時間點，以及我打算在自己的 App 裡怎麼落實。

TL;DR： 針對兩個尺寸類別做設計，姿勢交給系統處理。在外螢幕以及橫向的內螢幕上，各種列會轉為直向；只有直向的內螢幕保留橫向的列。⁴ 帶圖像的項目轉為直向，純文字項目維持橫向；直向列的頂端留給 Back 或 Close，緊接著是 Done 這類醒目動作。⁴ 除非是不捲動的沉浸式介面，內容都會透過水平安全區域相對於列產生偏移。² 在摺痕處，書本姿勢下「像警告這樣的元素會移到 trailing 一側」(4:09)，平放在桌面上時互動控制項會移到下半部，而「文章、動態消息、文件與列表這類連續捲動的內容不會位移」(3:46)。³ arrangement 是新的版面配置容器，分為 split 與 overlay 兩種；Apple 給的選擇規則就是你早已在用的那一套：水平或垂直堆疊對應 split，ZStack 對應 overlay。³

模式之前，先有一條規則

三場 Tech Talk 中的兩場與指南都在重複同一句話，而這正是應當作為設計起點的一句。Apple 設計團隊的 Vince 說：「人們會用各種不同的姿勢使用 iPhone Duo，你當然希望 App 在所有姿勢下都好看。但這並不表示要為每種姿勢做一套自訂版面配置。相反地，請專注在兩個尺寸類別：外螢幕的 compact width 與內螢幕的 regular width。避免使用固定寬度、斷點，或任何與特定螢幕綁定的數值」(3:50)。² 指南在談姿勢的那一節說的是同一件事。¹ Vince 另外補上一種可選的版面配置，適用於像筆記型電腦那樣架在桌面上的狀態，此時「媒體可以放在上方，可點按的控制項則位於下方穩固的底座上」(4:48)，前提是它「具備與其他姿勢相同的控制項與整體層級」(4:57)。²

取自 Apple 2026 年 9 月 9 日發表會直播太平洋時間上午 11 點 05 分的畫面：站立姿勢。指南列出的是「像書本一樣部分摺疊、平放在表面上，或以邊緣立起」。

以下所有內容都以這個基礎為前提，也正是可變尺寸 iPhone 檢查清單所檢視、iPad 尺寸連續可變那篇文章所說明的同一個基礎。如果版面配置是由尺寸類別、版面邊界與安全區域內距搭建起來的，Vince 的承諾是：「你的 App 應該已經能適應 iPhone Duo 了」(4:27)。²

側邊：什麼會挪過去，什麼會留下

在外螢幕上，原本位於頂端與底部的控制項「會移到螢幕右側，以便將垂直空間最大化，也讓右手拇指更容易觸及」(1:18)。² 側邊承載的是標籤列、工具列、Back 這類導覽控制項、狀態列，以及「會在 Live Activities 抵達時垂直展開」的 Dynamic Island(1:48)。² 在內螢幕上，橫向時列維持直向，直向時又回到橫向——那是「我們唯一保留橫向列的姿勢」(5:27)，原因是「App 內容擁有充足的垂直空間」(5:32)。² 在 Split View 中，「當 App 位於左側時，控制項也會移到螢幕左緣」(3:11)。² 而且列是對齊硬體的，因此「在由右至左的語言中，它仍停留在裝置的同一側」(4:21)。⁴

取自 Apple 2026 年 9 月 9 日發表會直播太平洋時間上午 10 點 59 分的畫面：裝置處於半摺狀態、內螢幕朝向觀眾，側邊安裝的控制項位於其右緣。

某個控制項會不會轉為直向，由兩件事決定。第一是它所在的容器。UI Frameworks 的 Anna 說：「請確認你用的是 TabView 或 NavigationStack 這類導覽容器所提供的列」(2:19)，因為來自自訂 UIToolbar、UINavigationBar 或 UITabBar 實例的內容「不會納入考慮」(2:58)。⁴ 在分割視圖中「只有 detail 欄參與其中」(3:43)，檢閱器則「不會擁有自己的」列(3:53)。⁴ 第二是項目本身的內容。直向列的「項目高度具彈性、寬度固定」(6:10)，這「讓直向列更適合僅含符號的項目表現方式」(6:13)。⁴ 因此「像 back 與 share 按鈕這種帶圖像的項目會把軸向改為直向；而像 edit 按鈕這種純文字的項目，則繼續留在水平軸上」(7:06)。⁴ Vince 的說法是講給設計師聽的：「對右側空間而言過寬的工具列項目，例如文字按鈕或分段控制項，在 iPhone Duo 上應該留在導覽列裡」(6:22)。²

排序規則很簡短。「把頂端留給 back 或 close 這類主要導覽控制項，其後才是 done 這類醒目動作」(4:47)。⁴ 在 SwiftUI 中，自訂的 Back 或 Close 使用 cancellationAction 放置位置(5:02)，醒目動作使用 topBarPinnedTrailing(5:24)；在 UIKit 中，則是讓 leading 項目的 leftItemSupplementsBackButton 維持預設的 false(5:06)，醒目動作使用 pinnedTrailingGroup(5:27)。⁴ 其餘項目維持原有分組，並由「一個垂直間隔元件在視覺上分隔頂端與底部的放置位置」(5:34)。⁴

這場談列的 Tech Talk 針對個別項目所給的規則，各附一句提示：⁴

• 判斷自訂項目的標準：「它只是在強化那個符號，還是承載了獨立的資訊？」(9:36)
• 數量應該放進標記，如此一來「文字加符號」的項目就變成僅含符號的項目，從而「在直向列中顯得自然」(9:23)；而「顯示金額的購物車按鈕」則維持橫向(9:52)。
• 像 Edit 這種在符號與文字之間切換的項目維持橫向；系統的 Edit 按鈕本來就如此，自訂的則要採用僅限水平的 AxisBehavior(8:11、8:32)。
• 自訂視圖或複雜視圖預設維持橫向(8:40)；如果它「確實支援直向的表現方式」(8:48)，那麼偏好直向的 axis behavior 可以讓它進入列中(8:54)。
• 即使項目顯示的是符號，也要為每個項目提供標題，因為「每當項目移入溢出選單或展開形態時，系統都會用到它」(7:44)。
• 鍵盤配件列「應該維持附著在鍵盤上，而不是移到垂直軸上」(10:00)。
• 自訂視圖可以讀取 toolbarVerticalEdge 環境屬性（在 UIKit 中是 trait），以判斷是否存在直向列(10:35)。

溢出是設計偏好得以表達的地方，這場 Tech Talk 給出五條規則：⁴

• 「預設情況下，項目會由下往上溢出」(13:23)；每個項目都可以帶有 high、low 或自訂的可見性優先順序，先「依群組」(13:36)分配，再在群組內分配。優先順序與溢出相關的 API 屬於 WWDC26 新增的工具列能力，本站關於 iOS 27 SwiftUI 的文章已有介紹；在 13:49 處，這場 Tech Talk 會把你導向 Apple 談 SwiftUI 新功能的 WWDC26 場次。
• 決定先壓縮什麼：在以導覽為主的視圖中，「工具列先壓縮，如此主要目的地仍可存取」(12:07)，這是預設行為；在以任務為主的視圖中，「標籤列先壓縮，以保留高頻使用的動作」(12:18)，用 toolbarCompressionBehavior 設定(12:22)。
• 把 App 自己的溢出選單併入系統的溢出選單，在 SwiftUI 中用 ToolbarOverflowMenu，在 UIKit 中用 additionalOverflowItems(12:36、12:43)，並讓刪節號只用於溢出(12:53)。
• 「像 Mail 裡的 Compose 或 Notes 裡的 New Note 這類高頻動作，應該屬於最後才移入溢出的那一批」(13:59)。
• 帶標記的項目「應該維持可見更久，以保住一眼可辨的特性」(14:11)。

直向列並非強制。像 Calculator 這種單頁面、重心偏下的版面配置，或只有 Close 一個工具列項目的表單，都可以用 toolbarVerticalBehavior 或 preferredVerticalBarBehavior 把這條列關掉(14:28、14:37、14:47)。⁴

置中，還是偏移

列挪到一側之後，「許多層次現在都不對稱了」(6:33)。² Vince 給出三種位置。多數內容採用偏移，以免被控制項擋住；「如果你的 App 是依水平安全區域內距對齊的，這個偏移會自動發生」(6:58)。² 有些 UI 仍以整片螢幕為準置中、不做偏移，這「很適合不捲動的沉浸式、視覺性強的介面，前提是你確定互動元素不會被右側的控制項擋住」(7:10)。² 兩者也可以混用：「滿版寬度的背景圖或頁首，搭配向內縮排的可捲動前景內容」(7:22)，只要「每個互動元素都位於那塊可捲動區域內，就不會有東西被蓋住」(7:28)。² 指南關於安全區域的說明還補上 Split View 的情況：對面那一側的邊緣可能承載另一個 App 的控制項，所以兩側邊緣的安全區域都有意義。¹

摺痕：位移

取自 Apple 2026 年 9 月 9 日發表會直播太平洋時間上午 11 點 08 分的畫面：螢幕的層結構。部分摺疊時，穿過中央的那道弧面就是指南所說的「folding region」。

Apple 設計系統團隊的 Human Interface Designer Maria 以一條原則開場：「為 iPhone Duo 做出色的設計，關鍵在於知道何時該調整」(2:25)。³ 許多介面「可以自然地繞著 reserved region 流動」(2:30)，其餘的則使用位移，也就是「依據可用空間調整既有元素的框架，即使裝置處於部分摺疊狀態，也讓重要內容保持可見、可觸及且不被遮擋」(2:39)。³ 這個模式有其適用範圍，「小至一個按鈕，大至整個容器或版面配置中更大的部分」(3:03)，並伴隨兩條規則：「如果某個元素能夠獨立調整，就讓它單獨移動。而當多個元素協同運作時，就一起移動它們，以保住彼此的關係」(3:17)，以及「留意過度的移動」(3:26)，因為「把一個元素移到離原本位置很遠的地方，會削弱它們之間的視覺關係」(3:29)。³ 她舉的例子是選取照片後跳出的快捷選單：與其把選單在 trailing 區域裡置中，不如讓「兩個元素一起移動，並沿著摺痕對齊」(3:39)。³

設計師最會倚賴的是那條例外：「文章、動態消息、文件與列表這類連續捲動的內容不會位移。這些體驗本來就透過捲動完成調整，因此在可用區域之間挪動它們反而會打斷連續性」(3:46)。³ Vince 從另一個方向說了同一件事：系統之所以把互動元素推離那道弧面，是因為「按鈕正好落在摺痕上時很難點中」(9:28)，這項行為已內建於「表單、警告、選單、工具列按鈕等等」(9:40)，而且「可捲動內容不需要避開這個區域」(9:57)。²

摺痕的走向決定了區域的劃分：書本姿勢下摺痕垂直延伸，區域就是左與右；平放在桌面上或直向持握時摺痕水平延伸，區域就是上與下。²³ 被位移的元素去往何處取決於姿勢，而 Maria 給的理由才是有用的部分。在書本姿勢下，「像警告這樣的元素會移到 trailing 一側。這讓它們更接近裝置闔上、體驗延續到外螢幕時它們將要出現的位置」(4:09)。³ 架在桌面上時，「上方區域很適合那些遠距離可見性更有價值的內容」(4:29)，而「下方區域很適合互動控制項」(4:39)，「媒體控制項這類可點按元素可以移到這裡，為觸控提供更穩固的表面」(4:43)。³ 談原則的那場 Tech Talk 也持相同看法：直向、部分摺疊時，「互動元素會移到螢幕下半部，既更容易觸及，也能讓裝置穩穩放在桌面上」(2:33)。² 當有多個區域都合適時，要貼合脈絡：裝置展開時，搜尋欄位「會善用多出來的空間」(5:00)，而隨著摺疊進行，它的「寬度與位置會隨之調整，以便始終位於所搜尋的視圖之上」(5:04)。³

這些大多由系統代勞。「動作表單、警告、選單與彈出式視窗都屬於輕量的情境化體驗，可以出現在 reserved region 之上」(5:23)，系統會「自動繞著 reserved region 重新配置元件的位置」(5:34)。³ 分割視圖會「透過調整寬度並把兩欄排成均等的 50/50 分割，讓兩欄都保持可見」(5:40)。³ 網格則是需要你自己負責的情況：在 Maria 設計的 Fitness 裡，「我可以保留外側邊界，同時加大鉸鏈周圍的間距，讓每個容器都待在各自的區域內」(5:56)。³ 她對所有例子的總結，就是這份設計綱領：「我們所做的是移動、調整尺寸或重新組織已經存在的東西。讓內容、功能與版面配置始終可用，如此無論人們以何種方式使用 iPhone Duo，都能獲得完整的體驗」(6:04)。³

Reserved region：位移背後的機制

Maria 在談自適應版面配置的那場 Tech Talk 中引入了這個術語：「新的硬體特性同樣在形塑可用空間。它們包括鉸鏈，以及橫跨外螢幕與內螢幕的兩顆相機。我們把這些稱為 reserved region」(0:37)，並建議把它們「當成你的版面配置本來就要適應的其他區域一樣」看待(0:53)，她舉的例子是 iPadOS 上的視窗控制項。³ 一共有三處：外側相機、處於運作狀態的內側相機，以及摺痕(1:00、1:18、1:32)。³ 開發者視角那篇文章收錄了指南對每一處的定義，也記下了我的查證結果——指南並未為這些 API 連結任何文件，因此本節只談機制。¹ UI Frameworks 工程師 Harry 介紹了這套 API：「在 SwiftUI 中，你可以透過 GeometryReader 或 onGeometryChange 修飾符取得的 GeometryProxy 來查詢 reserved region。使用 geometry proxy 上新增的 reservedRegion 方法，即可取得目前視圖中可用的區域。」(6:38) 在 UIKit 中，「你會用到 UIView 上提供的 reservedRegion 方法」(7:03)，而且「可以查詢某個 reserved region 的 frame 屬性，把它納入自己的版面配置」(7:07)。³

它們分為兩類。摺痕「由 division 類型的 reserved region 支撐，因為它把一塊較大的區域劃分成多塊較小的區域」(6:55)，而且「只有當有人摺疊裝置時才處於啟用狀態。攤平時它未啟用，寬度為零」(7:26)。³ 相機屬於 occlusion 區域：這類區域「不劃分區域，而是遮蔽區域」(7:54)，並且「相機啟用時它啟用，相機未啟用時它也未啟用」(8:12)。³ 未啟用的區域可以透過 includeInactive 選項查詢，而 Harry 認為值得留意它們的理由是一項設計判斷：「在網格類的版面配置中，只要存在 division 區域，無論它是否處於啟用狀態，你都可能更傾向使用偶數欄」(7:41)。³ 指南也把這一條重複為一項規則。¹ 截至主題演講當天太平洋時間下午 4 點 15 分，指南沒有為這些 API 連結任何文件頁面，而 Apple 的開發者頁面把 Xcode 27.1 beta 的時間標為「本月稍晚」。¹⁵

Arrangement：分割還是疊放

取自 Apple 2026 年 9 月 9 日發表會直播太平洋時間上午 11 點整的畫面：Apple 稱之為大上 80% 的內螢幕，也正是 arrangement 所面向的畫布。

Harry 的定義是：「在這些導覽容器與內容容器之間，還有一層版面配置容器。這些版面配置容器會依一組規則排列兩個視圖。它們稱為 arrangement」(9:20)。³ 這些規則接受的輸入是「視圖的水平與垂直尺寸類別、視圖寬度與高度之比，以及是否有處於啟用狀態的 division 區域」(10:37)，產出的則是：「我究竟該不該顯示這個視圖」(10:52)，以及若要顯示，「它的框架是什麼」(10:54)。³ 至於時程：「在 iOS 27.1 中，你可以在自己的 App 裡使用系統提供的 arrangement」(11:02)。³

在 SwiftUI 中，ArrangementView 接受一個 primary 視圖與一個 secondary 視圖(11:25)，樣式透過 arrangementViewStyle 設定(11:57)；在 UIKit 中，UIArrangementViewController 接受 primary 與 secondary 視圖控制器(11:39)。³ 作為預設值的 split 樣式，「在視圖寬大於高時水平分割」(12:13)，高大於寬時則垂直分割，也可以限制為單一軸向；如果無法在主軸上分割，它「會選擇只顯示單一視圖」(12:49)。³ overlay 樣式「傾向把內容上下疊放」(13:31)，而當裝置摺疊時，它「傾向把 primary 與 secondary 視圖並排放置」(13:51)，視圖可以透過 overlayArrangementZIndex 環境屬性察覺這一點，從而在收合形態與展開形態之間切換(14:01)。³

如何在兩者之間取捨，是這場 Tech Talk 裡最清楚的建議，指南也照單採納：「如果你在 App 的某些部分已經用 HStack 或 VStack 之類的元件實作了類似分割的版面配置，不妨考慮使用 split arrangement。如果你已經用 ZStack 之類的元件實作了類似疊放的版面配置，不妨考慮使用 overlay arrangement」(14:44)。³ 若沒有現成的模式，則在「視圖之間存在明確的前景／背景關係時」(15:10)使用 overlay，例如 Accessibility Reader 中浮在可讀內容之上的控制項；在「更接近主從關係時」(15:32)使用 split，例如 Podcast 與它的文字稿，此時「兩者都不被遮蔽這一點很重要」(15:43)。³ 兩條限制——導覽容器應包在 arrangement 外面而不是放在裡面，以及不要把 arrangement 放進 List 或 ScrollView——分別位於 Tech Talk 的 16:15 與 16:26；指南只寫明了前者，開發者視角那篇文章引用了那句話。¹³

內螢幕：三種誠實的版面配置

「你不會想要一個單純被拉長的 iPhone App」(7:39)。² Vince 提出三種形態。其一是分割視圖，它能「同時呈現 App 層級中的多個層次」(7:46)，條件是這套層級「在外螢幕與內螢幕之間不發生變化」(7:51)，因為人們「使用 App 時可能頻繁開闔裝置，所以它必須在內外都可預期、保持一致」(7:59)。² 其二是重排，參照 Music 的做法，讓「垂直堆疊的版面配置」(8:15)在「水平空間更充裕時變成雙欄版面配置」(8:18)。² 其三是把標籤列「在內螢幕上以側邊欄形式」呈現(8:26)，這「最適合像 Health 這個例子一樣資訊密集的 App」(8:33)。² 指南裡的 Mail 例子屬於分割視圖這一類：闔上時是列表或一封郵件，展開時兩者並排。¹

表單有自己的規則。在外螢幕上，「表單的控制項同樣會移到側邊」(8:46)；對於只有一個工具列按鈕的表單，你可以關掉這項行為，此時「表單會在前置相機前方稍作收住，狀態列則自行調整位置」(9:04)。² 在內螢幕上，表單預設「使用標準的橫向列」(9:13)，而當裝置部分摺疊時，它們會「側移開來，避免正好停在摺痕上」(9:20)。² 談列的那場 Tech Talk 補上一條關於放置位置的例外：內螢幕上的表單「預設置中，其中的項目維持橫向」(4:03)，但透過 preferredPlacement API，「放在左側的表單不會出現直向列，放在右側的表單則會獲得一條」(4:11)。⁴

檢視清單

談列的那場與談自適應版面配置的那場 Tech Talk，各自都以一份檢視清單收尾，這裡把它們合成一份。談列那場的收尾清單(15:10)是：用最新的 SDK 建置，因為直向列是依 SDK 選擇加入的(2:06)；檢視各個列及其順序(4:41)，並更新自訂項目使其能夠直向排列；以及分配可見性優先順序，「好讓系統能夠適應」(15:26)。⁴ 接著是談自適應版面配置那場(16:40)：「先從檢視 App 中的置中版面配置開始。想一想能否把它改成雙欄版面配置，或者在那個使用情境下哪一種位移模式更合理」；使用標準容器與呈現方式，以取得那些免費的行為(16:49)；自訂的分割或疊放版面配置則改用 ArrangementView；以及「找出視圖中優先順序最高、由你手動排列的控制項，並考慮採用 ReservedRegions API，在必要之處實作自己的位移」(17:06)。³

素材，截至 9 月 10 日

Apple 的 Design Resources 頁面現在提供 iPhone Duo 的產品外框套件，格式為 Photoshop 與 PNG：兩種外觀、五種姿勢，內螢幕的鏤空尺寸為 2853 × 2007 像素，這是 App Store Connect 的截圖尺寸，而不是面板的尺寸；授權依循 design resources 的條款，僅限用於 Apple 平台軟體的示意圖。iPhone Duo 目前還沒有 Figma 或 Sketch 檔案。App Store Connect 的截圖規格列出外螢幕為 1398 × 2034 像素，內螢幕為 2007 × 2853 像素，以 3x 換算就是 669 × 951 點。第二天的整理收錄了套件內容、截圖尺寸，以及頭 24 小時內出現的社群示意圖、範例套件與代理技能。⁶

我打算怎麼運用

我有三款 iPhone App，指南把它們分得很乾淨。這個分法是我的解讀，不是 Apple 的。

• Get Bananas 是一份列表。列表不會位移；只要我繼續使用系統容器，標籤列與工具列會自行移到側邊。唯一的設計判斷是可見性優先順序：新增項目這個動作就是我的 Compose，因此它應該是最後才溢出的那一個。
• Reps 把每一組記錄成一列，包含重量、次數與一個記錄動作，訓練過程中呈網格排列，正是 Maria 舉的 Fitness 例子。判斷是：書本姿勢下，三欄的一列會讓中間那欄正好壓在鉸鏈上，因此網格改為兩兩成對的雙欄。桌面姿勢下，記錄動作放在下半部。取捨在於每組多點一次，換來的是目標永遠不會落在摺痕上——用 Vince 的話說，那裡「按鈕很難點中」(9:28)。² 組間休息計時器留在上方，也就是 Maria 所說很適合「遠距離可見性更有價值的內容」(4:29)的那個區域。³
• Return 繪製健康圖表，屬於捲動內容。目前圖表與它的時間範圍選擇器同處一個垂直堆疊，依 Harry 的規則，這個堆疊對應的是 split arrangement，能在裝置摺疊時讓兩者都保持可見；而圖表本身永遠不該位移。

2026 年 10 月 17 日更新：第四款以這種方式打造的 App，Kiradex，已經以 27.1 SDK 推出。一個 TabView、幾個 NavigationStack 與工具列項目，不需要任何 Duo 專屬程式碼，就把它的各種列放到了側邊；一個 arrangement view 分割展開的螢幕，並在書本姿勢下把分隔線放在摺痕上；一個 onHingeChange 則在手機展開時重播 App 的開場動畫。它在每種姿勢下的表現請見 kiradex.app/duo；實作範例逐一走過每一種姿勢。

重點整理

給設計師： - 關注兩個尺寸類別，而不是各種姿勢：外側是 compact width，內側是 regular width。¹ Apple 的設計師建議的唯一可選補充，是一套維持相同控制項的桌面姿勢版面配置。² - 圖像轉直向，文字留橫向；側邊列頂端是 Back 或 Close，其後是 Done；高頻動作與帶標記的項目最後才溢出。⁴ - 捲動內容永不位移；警告、選單、表單與控制項則會位移，去向取決於用途：書本姿勢下警告去 trailing 一側，桌面姿勢下去上方區域，觸控控制項去下半部。²³

給設計工程師： - 摺痕是 division 區域，僅在摺疊時啟用，攤平時寬度為零；內側相機是 occlusion 區域，僅在相機運作時啟用；兩者都可以透過 GeometryProxy 或 UIView 查詢。³ - arrangement 隨 iOS 27.1 一併推出：堆疊對應 split，ZStack 對應 overlay，導覽容器留在它們外面。³ - 使用導覽容器提供的系統列，否則直向版面配置根本不會發生。⁴

常見問題

每種姿勢都需要一套版面配置嗎？

不需要。Apple 建議針對兩個尺寸類別做設計——外螢幕的 compact width 與內螢幕的 regular width——並避免固定寬度、斷點或與螢幕綁定的數值。¹² 談設計的那場 Tech Talk 提到的唯一可選補充，是一套控制項與層級都保持一致的桌面姿勢版面配置。²

在 iPhone Duo 上，哪些控制項會維持橫向？

純文字項目、像分段控制項這種對側邊列而言過寬的項目、像 Edit 這種在符號與文字之間切換的項目，以及鍵盤配件列；此外，如果你願意，在重心偏下的單頁面 App 或只有一個工具列項目的表單中，也可以讓整條列維持橫向。²⁴

什麼是位移？

這是 Apple 的一種模式：移動、調整尺寸或重新組織既有元素，使其在裝置部分摺疊時仍然可見、可觸及。警告、選單、彈出式視窗、表單與工具列按鈕由系統自動處理；捲動內容則不在此列。²³

arrangement view 與 reserved region 的 API 何時推出？

談自適應版面配置的那場 Tech Talk 表示，系統提供的 arrangement 可在 iOS 27.1 中用於你自己的 App；Apple 的開發者頁面把 Xcode 27.1 beta 的時間定在 9 月稍晚。設計指南目前尚未為這兩套 API 連結任何文件。¹³⁵（10 月 26 日：它們已隨 iOS 27.1 推出，這個版本於 10 月 23 日來到 iPhone Duo；Apple 為 ArrangementView、UIArrangementViewController 與 reservedRegions(kind:options:) 寫的參考頁面都列出 iOS 27.1，沒有 beta 標記。⁷）

捲動內容必須避開摺痕嗎？

不必。談設計的那場與談自適應版面配置的那場 Tech Talk 都把捲動內容排除在外；它本來就透過捲動完成調整。²³

參考來源