Juxt
JUXT Design
文章 · 收錄於 2026.09
MGN-BLOG-DESIGNIN
索引 · 部落格

為 iPhone Duo 設計

控件外移、避開折痕、可縮放版面:讓同一個 App 在 Duo 的多種姿態與雙螢幕上仍保持一致。

2 分鐘閱讀

Apple 第一支摺疊 iPhone,要的不是為每種硬體狀態另做一套「摺疊模式」,而是讓同一個 App 在姿態與兩塊螢幕之間自適應。尺寸、長寬比、哪一面在作用都在變時,設計目標仍是:體驗像同一個產品。

先看官方材料:iPhone Duo for developersHIG:Designing for iPhone Duo,以及技術講座 Design for iPhone DuoRaise the barMultiple displays and scenes

版面與 HIG 原則

把 Duo 當成同一產品的多種姿態。優先用系統的 size class(compact / regular)、layout margins 與 safe area insets,不要為每個姿態各做一套自訂版面。若某個姿態必須特製,也要維持階層與導覽語言一致,讓它仍像同一個 App。

控件往外緣靠,好保住垂直內容高度。裝置摺起時,內容應離開中線,而不是壓在折痕下。已經能在 Split View、Picture in Picture 裡正常運作的 App,距離就緒更近:它們本來就容忍縮放與長寬比變化。

外螢幕。 Safe area 會把內容從垂直控件後方推開。沉浸式、不可捲動的 UI 可以對齊整塊螢幕置中。也可以混合:背景全寬、文字與可互動 chrome 內縮。

內螢幕。 善用寬度:split view、雙欄階層適合較大畫布。預設不要把窄螢幕直欄硬塞在寬內螢的正中央。

Sheet。 外螢幕上的 sheet 會改用垂直控件;內螢幕維持熟悉的水平 bar。摺起時 sheet 會滑開,避免停在折痕上。

避開折痕。 半摺時系統會把可互動元素推離中心。固定 chrome 不要壓在鉸鏈上。可捲動內容是實務例外:使用者能捲過折痕;固定控件不行。

一句話目標:一個會隨尺寸與姿態適應的體驗,不是平行的兩套 UI。

垂直 Bar:設計系統層級的改變

較寬的長寬比會把原本上下的 bar 推到側邊:想像熟悉的 chrome 旋轉 90°,進入共用的垂直 bar 區域。外螢 landscape 更好觸達;內螢 landscape 維持一致;portrait 仍是大家熟悉的水平配置。

這是 opt-in 的平台行為:用最新 SDK 重建,並採用系統導覽容器時才會生效:

  • SwiftUI:NavigationStack / NavigationSplitView 加上 toolbar API
  • UIKit:UINavigationController / UITabBarController

自訂的 UIToolbarUINavigationBarUITabBar 內容不會自動搬過去。對設計系統來說,這代表:不要再把頂/底 bar 當成永遠水平的 primitive。要建模的是 bar items、overflow 與優先級,讓同一套設定能水平或垂直呈現。

在共用區域裡,navigation、toolbar、tab chrome 共存。Split view 裡只有 detail 欄參與;inspector 不會另有一條側 bar。即使在 RTL,bar 仍對齊硬體邊緣,不會鏡射出令人困惑的第二條垂直堆疊。

在 Figma 與程式裡都該先對齊的規則:

  • 垂直堆疊頂端放 back / close
  • 主要動作釘在 trailing(心智位置相同,軸向變了)
  • 優先 symbol-only;overflow 與展開態一定要有標題
  • 數量仍可用 badge
  • 自訂視圖:無法壓成垂直堆疊時,用 AxisBehaviorverticalPreferredhorizontalOnly

Overflow 在外螢 landscape、有鍵盤時更常見。用 visibility priority、overflow menu,必要時再補 extra overflow items。先決定壓縮 toolbar 還是 tab。Opt out 應少見:Apple 舉的例子包括偏底部操作的計算機類 UI,或只有 close 的 sheet。

系統設計者要把每頁的 bar 配置,當成與 Live Activities、狀態列共用的垂直預算,而不是無限水平 chrome。

鉸鏈 API ≠ 版面 API

鉸鏈狀態/角度 API 用於互動與效果:視差、輕微回饋、姿態感的動態。版面應跟 arrangement、reserved region API(鉸鏈分割、相機遮擋、位移)走,不要用鉸鏈角度驅動 Auto Layout。

多工包含 Split View。多視窗近似 iPad,但有限制:不會在外螢幕開出新 window。Scene accessories(例如主任務在內螢、外螢放伴隨 UI,提詞器這類)是雙螢幕編排模式。當成 scene 角色來想,不要整包 App 為相機硬體重做。

設計系統先改什麼

  1. 可縮放地基:已尊重 size class 與 safe area 的欄、堆疊、sheet
  2. Bar 清單:遷到系統容器;標出必備、trailing 強調、優先進 overflow 的項目
  3. 對折痕安全的 chrome:主要動作不放鉸鏈;固定 UI 內縮;捲動內容可越過折痕
  4. 雙螢幕角色:只有第二面真正承擔伴隨任務時才用;主階層仍靠一套連續自適應版面

不要一開始就把「摺起/展開」畫成兩個品牌。先從 compact/regular、safe area,以及一套撐得住垂直配置的 bar item 清單開始。姿態草圖,等系統規則清楚再畫。

索引 · 相關文章

延伸閱讀

Git

給設計師的 Git for Dummies

前幾天在 Threads 隨口寫了一句:凡採用 AI 工作流程的 UI/UX 設計師(或非工程人員),都該先從 Git 學起,否則會很難跟人協作。 底下很快出現兩種聲音。一種是「開一堂給設計師的 Git 101 啊」,另一種是「套 skill 就好,學什麼學」。還有人問得更直接:設計師出的圖檔,本來就不能 `git commit` 吧?每個版本都是獨立檔案,也沒有「很多人共同畫一份 pages」這種事。 這篇主要想分享給開始用 AI 碰程式、但又還沒把 Git 當成自己工具的人。不是要你變成工程師,也不是叫你把 Figma 檔丟進 GitHub。只是我自己越來越覺得:當你真的能開 branch、交 coded prototype,有幾個詞不懂,跟工程師講話會卡住,叫 AI 救場也會救錯地方。 Claude Code 幫你生出一頁 HTML,那還只是你自己的草稿。要讓別人打開、留言、一起改,

GitAiCursor
Figma

用 Cursor 一句話跑 Figma Weave 工具

Figma 8 月 11 日在 Release Notes 裡寫了一則更新,標題很直接: Starting today, you can run your Figma Weave tools from clients like ChatGPT, Claude, or Cursor using the Figma MCP server. Describe what you need and the agent finds the tool, runs it, and returns the result in your conversation. 這篇主要想分享給:已經在用 Cursor(或 Claude)做事,手上又有重複生成需求——mockup、icon、社群尺寸延展——的人。不是再介紹一次 Weave,而是把「這能力是什麼、怎麼接、現在值得先做什麼」寫清楚。 ⸻ ▍官方在講什麼 公告列

FigmaWeaveMcp