我的知識庫

UIUX · 2026-10-22

閱讀時間約 21 分鐘

今天先把 iPhone Duo 的 API 名稱對清楚：昨天文章引用的二手來源把查詢摺痕的方法寫成單數 reservedRegion()，Apple 自己的 Tech Talk 與開發者論壇寫的是複數 reservedRegions(kind:options:)，SwiftUI 掛在 GeometryProxy，UIKit 掛在 UIView。iPhone Duo 明天（10 月 23 日）開賣，首批評測昨天（10 月 21 日）出爐，所以今天的重點是兩件事：Apple 一手資料補上了哪些規則（包含一條會直接吃掉觸控的規則），以及評測與 Smashing、Ben Walsh 的新文章對實務有什麼用。

承接 昨日 UIUX 的「裝置形狀改變時哪些細節該動」，今天補的是答案的另一半：不動的東西，系統只保證到哪裡為止。

📖 學

一、昨天待驗項對帳

昨天的待驗今天查到狀態
reservedRegion 方法名稱Apple Tech Talk「Strike a pose with adaptive layouts on iPhone Duo」摘要的範例為 proxy.reservedRegions(kind: .division)；Apple 開發者論壇的 Group Labs 彙整寫 geometry.reservedRegions(kind:options:layoutDirectionBehavior:) 與 UIView.reservedRegions(kind:options:)；另一篇 BleepingSwift（9 月 23 日）寫法相同。三處都是複數，與昨天二手來源的單數寫法不一致已確認：複數；昨天的單數寫法是錯的
iOS 27.1 的 arrangement 容器Tech Talk 摘要與論壇彙整都有：SwiftUI 的 ArrangementView、UIKit 的 UIArrangementViewController，分 Split 與 Overlay 兩種，iOS 27.1 起可用。Split 把範圍對半分給主、副兩個視圖，寬大於高時水平切、高大於寬時垂直切；Overlay 平時偏向上下擺，裝置摺起時改成並排。昨天二手來源說「對應 HStack/VStack 與 ZStack、不能放進 List 或 ScrollView」，這兩句 Apple 摘要都沒有容器已確認存在；對應關係與限制查不到，不能判
外螢幕點數與兩螢幕比例Tech Talk 摘要與論壇彙整都明講沒有給點數，要用尺寸類別而不是寫死數字Apple 一手資料沒有公布；我的 466 點推論與 2.3% 差距仍無法驗證
HIG「Designing for iPhone Duo」原頁今天再抓一次，仍只拿到頁面標題仍沒有原文
HomeView pt 規格Apple 設計「What’s new」頁最新仍是 10 月 13 日（Widgets 加入 HomeView、Live Activities 加入限寬版面），其後沒有新條目，頁面沒有 pt 數值仍未公布
Pitre 評分規則、Guidelines 遵守率今天針對 Figma Specs 與 Guidelines 再搜尋，結果仍是各媒體的發表報導，TechBriefly 與其他轉述都重述「目標是更可預測的輸出，不是保證遵守」，沒有任何量化測試查不到，不能判
GOV.UK 後續版本GitHub API 的最新發行仍是 v6.6.0（2026-10-15T10:17:05Z），前一版 v6.5.1 為 2026-09-14，沒有更新的版本已確認：沒有 6.6.0 之後的版本
11 月 13 日實機字高、USWDS 後續今天沒有重新搜尋待驗

這張表有一個值得記的教訓：昨天我已經把方法名稱標成「二手來源，沒有在 Apple 頁面核對」，今天核對後確實有錯。二手整理文章對型態與規則的概括通常可用，但 API 的拼字必須回到一手文件。本文所有網頁都經網頁抽取摘要，不是我讀完整原文。

二、保留區域：Apple 一手資料多出來的規則

Tech Talk 摘要把「保留區域」分成兩種：division（分隔，主要是摺痕）與 occlusion（遮擋，例如外螢幕鏡頭、內螢幕的 FaceTime 鏡頭、Dynamic Island）。每個區域有啟用與未啟用兩種狀態，攤平或鏡頭沒在用時為未啟用。BleepingSwift 補充區域物件帶有 frame、margins、isActive、id：按鈕要用完整的 frame 避開，純裝飾元素才可以用 margins 抓得更貼近。這部分是二手轉述，我沒有在 Apple 文件核對屬性名稱。

Apple 論壇彙整裡有一條我認為最該看的：自訂 UI 若與保留區域重疊又沒採用這組 API，「觸控事件會被抑制」。這與昨天二手來源說的「警示、選單、Sheet、按鈕會自動避開」是不同層次的事：系統元件會自己閃避，自訂元件不只會被遮住，連點都點不到。對設計師而言，這代表「畫面上看起來能按」與「實際能按」在摺痕區可能脫節，驗收標準要從視覺檢查改成真的去點。這是論壇彙整的摘要，我沒有實機驗證。

同一份彙整還有幾條可以直接變成設計檢查項：

規則內容來源
版面判斷依據用 horizontalSizeClass 與 verticalSizeClass，不要用 userInterfaceIdiom、方向或螢幕邊界；外螢幕 compact width，內螢幕兩個方向都是 regular論壇彙整、Prepare your app 摘要
Tab bar每個項目要同時提供圖示與標題，因為直式列只用圖示，純文字項目在直式模式不會顯示論壇彙整
自動搬家的範圍只有 UITabBarController、UIToolbar、NavigationSplitView 這類系統元件會自動搬到側邊；自訂列要自己查 toolbarVerticalEdge（SwiftUI）或 traitCollection.verticalBarEdge（UIKit）論壇彙整
摺痕角度onHingeChange 給離散狀態與連續角度，但角度只拿來做效果與互動，不拿來決定版面；版面交給 arrangement 與保留區域論壇彙整
非鏡頭內容外螢幕除了鏡頭預覽與 AlarmKit，不能顯示一般內容；系統隨時可能收回，動畫要能乾淨地開始、暫停、停止論壇彙整

「純文字項目不會顯示」這條與昨天表格寫的「純文字項目留在水平列」並不矛盾，兩者說的是不同容器：Crosley 談的是工具列上的 Edit 這類按鈕，論壇談的是 Tab bar 項目。但 Tab bar 若只有標題沒有圖示，在直式列裡就消失，這個差別會讓只有文字標籤的 Tab 設計直接出問題。

三、SDK 版本決定 App 看起來像什麼

Prepare your app for iPhone Duo 的 Tech Talk 摘要與論壇彙整對 SDK 版本的描述一致：

用哪個 SDK 建置在 iPhone Duo 內螢幕上的樣子
iOS 26 以前能跑，但被限制在狀態列與鏡頭左側的區域，橫向兩側黑邊、直向四周都有黑邊
iOS 27往狀態列左側多延伸一些，仍留有邊距
iOS 27.1滿版；標準導覽與工具列按鈕在狀態列下方直式排列；進階 API 都要這個版本

首批評測印證了這個差別。9to5Mac 的評測（10 月 21 日）寫到舊 SDK 的 App 會有「兩側大塊黑邊」或「浮在中央、四周被黑邊包住」，iOS 27 的 App 則會填滿內螢幕的大部分，只在右緣留狀態列空間；評測者也說一週內已有不少開發者推出完整適配的版本，差別「很大」。這是單一評測者的觀察，我沒有統計哪些熱門 App 已適配。Gadget Review 同日的文章則明講截圖只涵蓋部分方向與狀態，第三方 App 的實際反應要實測。搜尋摘要另轉述有評測者批評右側控制區在按鈕很少的頁面仍然是一條不能放內容的長條，這出自搜尋結果摘要，我沒有讀到對應的原文，不能歸給特定媒體。

這個批評值得單獨想：固定的控制區是 Apple 用一致性換來的，代價是控制少的頁面浪費空間。設計上能做的不是自己改位置（那會讓自訂列變成例外），而是讓內容在這條長條旁邊自然延展，並把真正的主要動作放進系統列。

四、Smashing 10 月 21 日：Intercom 如何重整導覽

Smashing 在 10 月 21 日刊出 Pranava Tandra 的《Redesigning Complex Navigation》，講 Intercom 團隊如何重整資訊架構、以清晰度當作每個決定的依據。我這次沒能抓到這篇文章本身（我嘗試的兩個網址都回 404，Smashing 的文章列表頁摘要也沒列出它），內容只有搜尋結果的一段簡介：把用處不大但佔位置的功能搬進相關流程或設定選單、把圖示標籤做成一次攤開的總覽，而不是逐一 hover。

同一位作者在 Intercom 部落格有一篇《Designing for clarity》，日期是 2025 年 1 月 24 日，我抓到了這篇。它交代問題是產品成長後導覽像「迷宮」：流程難找、設定分散、標籤混亂；四項原則是把相似功能合併、建立專屬的 AI 與自動化區、減少次層導覽雜訊、把個人設定整合成單一區塊；做法是使用者訪談與卡片分類、依使用者流程而不是工程結構對應功能、低擬真原型測試、多輪修正。文章沒有給導覽項目前後的數量，也沒有量化成效，只引用一位使用者說「終於合理了」，內部則是功能放哪裡的決定變快。兩篇作者與主題相同，Smashing 版是否為這篇的改寫，我沒有讀到全文，不能斷定。

這一組資訊的價值在做法，不在成果數字：「依使用者流程而不是工程結構」這個原則可以直接拿來檢驗自己的導覽。結論有保留，因為成效只有定性引述。

五、Ben Walsh 的 Figma 對比外掛實測

Smashing 10 月 19 日有一篇談 Figma 無障礙外掛的文章，搜尋摘要把作者指向 Ben Walsh，說他手測了所有主要的對比外掛，涵蓋 WCAG、APCA 與批次檢查。Ben Walsh 自己網站上同題文章的頁面標示 10 月 20 日，摘要說他測了 18 個外掛、使用人數、價格與更新狀態都在 2026 年 10 月核對過；但我抓到的頁面只有標頭與導覽，沒有內文，所以每個外掛的推薦、失敗案例與數字我都無法報告。這個題目我只能指出文章存在、範圍是 18 個外掛。

不過它提的測試維度值得借用，我用兩個灰色做了一個自己的驗證（與 Walsh 的測試結果無關）：用 WCAG 2 的公式算，#767676 在白底上是 4.542，剛好通過一般文字的 4.5；#777777 是 4.478，只差一階就不過。外掛若把比值四捨五入顯示成 4.5，就會把後者誤判為通過。另外 #949494 在白底為 3.033，勉強過非文字元件的 3 比 1。同一個藍色 #0a84ff 在黑底為 5.757、在白底只有 3.647，說明同一個品牌色在兩種模式要分開驗。這些是我用公式算的，不是外掛輸出。

🧠 記

  • reservedRegions（複數）： SwiftUI GeometryProxy.reservedRegions(kind:options:layoutDirectionBehavior:)、UIKit UIView.reservedRegions(kind:options:)；類型為 division（摺痕）與 occlusion（鏡頭、Dynamic Island）；iOS 27.1 起。
  • 觸控規則： 自訂 UI 重疊保留區域又沒採用 API，論壇彙整稱觸控會被抑制；視覺上能按不等於能按。
  • ArrangementView： Split 對半分、依長寬決定軸向；Overlay 平時上下、摺起並排；iOS 27.1。
  • Tab bar： 圖示與標題都要有，直式列只用圖示；只有系統元件會自動搬到側邊。
  • SDK： iOS 26 以前黑邊限縮、iOS 27 多延伸、iOS 27.1 滿版。
  • 對帳： 方法名稱昨天寫錯（單數）；Apple 沒有公布點數；HIG 原頁仍抓不到內文；HomeView pt、Pitre 評分規則、Guidelines 遵守率仍查不到；GOV.UK 最新仍是 6.6.0。
  • 對比數字（自算）： #767676 白底 4.542 通過、#777777 4.478 不過。

邊界： 本文所有網頁內容（Apple Tech Talk 兩支、Apple 開發者論壇、BleepingSwift、Apple 設計「What’s new」頁、9to5Mac、Gadget Review、Intercom 部落格、Ben Walsh 網站、Smashing 與 NN/G 的列表摘要、GitHub API）都經網頁抽取摘要，沒有讀完整原文，也沒有在 iPhone Duo、Device Hub 或 Xcode 驗證。Apple HIG 的 iPhone Duo 頁仍只抓到標題。Smashing 的 Intercom 文章與 Ben Walsh 的外掛內文我沒讀到。「觸控被抑制」是論壇彙整的一句摘要，沒有實測。右側控制區浪費空間的批評出自搜尋結果摘要，來源媒體不明。對比數字是我用 WCAG 2 公式自算，沒有用外掛實測。

✍️ 實踐

用 40 分鐘為自己的 App 或網站做一次「先找最容易壞的東西」的清查。

  1. 在程式碼裡找會寫死裝置形狀的地方，這些是在 iPhone Duo 上最先壞的：
grep -rn "UIScreen.main.bounds\|userInterfaceIdiom" --include=*.swift .

每一筆都問：能不能換成尺寸類別或視圖自己的邊界。

  1. 打開每個 Tab bar 與側欄項目，確認都同時有圖示與標題。只有標題的項目，在直式列會消失。
  2. 列出所有自訂的導覽列、浮動按鈕、底部 Sheet，標出哪些可能跨過畫面中線。對這些元件，在 Xcode 27.1 的 Device Hub 模擬器裡摺起來，實際用手點，不要只看畫面。
  3. 在內螢幕橫向確認右側那條控制區旁邊，內容有沒有自然延展，還是留下一塊死空間。
  4. 用下面的腳本檢查你的文字色與背景色，並把臨界值附近的兩組顏色特別記下來：
def lin(c):
    c /= 255
    return c / 12.92 if c <= 0.03928 else ((c + 0.055) / 1.055) ** 2.4
 
def lum(h):
    r, g, b = (int(h.lstrip('#')[i:i+2], 16) for i in (0, 2, 4))
    return 0.2126 * lin(r) + 0.7152 * lin(g) + 0.0722 * lin(b)
 
def ratio(a, b):
    hi, lo = sorted([lum(a), lum(b)], reverse=True)
    return (hi + 0.05) / (lo + 0.05)
 
print(round(ratio('#767676', '#ffffff'), 3))  # 4.542
print(round(ratio('#777777', '#ffffff'), 3))  # 4.478

我跑出來是 4.542 與 4.478。拿這兩組去測你正在用的 Figma 對比外掛，看它顯示的是 4.54 與 4.48，還是把後者四捨五入成 4.5。 6. 為你的導覽做一次盤點：把每個一級項目寫在便利貼上，標出它對應的使用者流程，而不是團隊分工；對應不到任何流程的項目，列為搬進設定或相關流程的候選。

🔗 延伸學習

💬 問 AI

我想為「可摺疊 iPhone 的保留區域」與「導覽重整」做一次設計盤點。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、版本號、數字或引文,也不要給任何投資或財務建議。
 
背景(請當待查證主張):
1. Apple 的 iPhone Duo Tech Talk 與開發者論壇指出:iOS 27.1 起,SwiftUI 以 GeometryProxy.reservedRegions(kind:options:layoutDirectionBehavior:)、UIKit 以 UIView.reservedRegions(kind:options:) 查詢保留區域;類型分 division(摺痕)與 occlusion(鏡頭、Dynamic Island)。
2. 論壇彙整稱:自訂 UI 與保留區域重疊又沒採用這組 API,觸控事件會被抑制。
3. 論壇彙整稱:Tab bar 項目要同時有圖示與標題,直式列只用圖示;只有系統元件(UITabBarController、UIToolbar、NavigationSplitView)會自動搬到側邊。
4. ArrangementView(UIArrangementViewController)的 Split 把範圍對半分並依長寬決定軸向,Overlay 平時上下、摺起並排。
5. 我自算:WCAG 2 下 #767676 在白底為 4.542,#777777 為 4.478。
6. Intercom 部落格(Pranava Tandra,2025-01-24)的導覽重整原則:相似功能合併、AI 與自動化專區、減少次層導覽雜訊、個人設定整合;方法為訪談、卡片分類、依使用者流程對應功能、低擬真原型。
 
請做:
A. 逐點驗證 1 到 6,標示「成立/部分成立/查不到」並附一手連結;特別確認觸控抑制的確切條件、Tab bar 規則在 HIG 原文的措辭,以及 Apple 是否公布兩個螢幕的點數。
B. 我的 App 有自訂底部列與一個跨中線的浮動按鈕,請列出在可摺疊裝置上最可能出問題的 5 個位置,各附「不靠肉眼」的檢查方式。
C. 說明為什麼 4.478 不能四捨五入成 4.5 通過,並設計一個 5 分鐘的流程驗證任一對比外掛的進位行為。
D. 教我用「依使用者流程而不是工程結構」的原則,為一個有 12 個一級導覽項目的後台做卡片分類:要找幾位受測者、怎麼分析、什麼結果代表該搬進設定。
不要評論公司或人事,只談設計實務、量測方法與證據強度。

反向連結