Apple 在 10 月 22 日公布了第一份官方的 iPhone Duo 適配 App 名單（50 個以上），並宣布 App Store 會替用 iOS 27.1 SDK 建置的 App 標上「Made for iPhone Duo」。這同時回答了昨天最大的待驗項：哪些主流 App 已經適配，現在有了一手來源，雖然只是「點名」而不是完整清單。另外兩條線在今天各出一篇新資料：NN/g 在 10 月 23 日發表 521 份問卷的〈AI in UX〉調查，Smashing 同日發表 Vitaly Friedman 的〈Accordion Icons: Which Work Best?〉，後者是一個小到可以今天就拿去改自己產品的案例。
承接 昨日 UIUX：昨天看第一批評測，今天看 Apple 自己怎麼示範好的適配，以及它示範的設計姿態（半摺）有沒有評測沒講到的東西。本文所有網頁都經網頁抽取摘要，不是我讀完整原文，沒有任何實機在我手上。
📖 學
一、昨天待驗項對帳
| 昨天的待驗 | 今天查到 | 狀態 |
|---|---|---|
| 各主流 App 適配狀態 | Apple 新聞稿與 MacRumors 10 月 22 日的整理點名 Netflix、Prime Video、MLB、Zoom、Slack、Lyft、Word、Outlook、Flighty、Fantastical、Things、Bear、Instagram、NYT Cooking、DoorDash、Yelp 等；MacRumors 說「50 個以上」。名單以「包括」開頭，所以沒被點名不等於沒適配 | 部分確認：點名者有一手來源；Spotify、TikTok、YouTube 在我讀到的摘要中沒出現，仍無法判定 |
| WorksOnDuo 追蹤站把 Instagram 標為「未確認」 | Apple 名單有 Instagram，追蹤站的「未確認」確實只是沒有公開證據 | 已確認：昨天「未確認不等於沒適配」的判讀成立 |
| 外螢幕與內螢幕的點數 | 今天讀到的 Apple 與 MacRumors 頁面都沒有點數 | 仍未公布 |
| WCAG 3 對比演算法 | W3C 編輯草稿仍是 2026 年 10 月 7 日版，文字對比判準仍寫「待決定」 | 仍待定 |
| Pitre 的 69 比 100 評分規則 | 我打開 ds-contracts-poc 的 PR 183（基準記分板），摘要說它「不聲稱 V1 完成」、「5% 門檻」，但沒有揭露評分公式；另有 PR 133 提到 72 張截圖中 33 張寬了一像素，那是視覺比對的修正，與 69 比 100 是不同的測量 | 仍查不到評分規則；不能判 |
| Apple 設計「What’s new」頁有無新條目 | 今天抓取回 500 錯誤 | 沒能查，維持昨天狀態（10 月 13 日最新） |
| HomeView pt 規格、11 月 13 日實機字高、Guidelines 遵守率 | 沒有新資料，11 月 13 日也還沒到 | 待驗 |
二、Apple 的三階分級，現在有了名字和標籤
昨天整理的三階 SDK 對照，今天由 MacRumors 在「Made for iPhone Duo」那篇用 Apple 的說法重述：用 iOS 27.1 SDK 以上建置的 App 填滿整個內螢幕，且工具列垂直排列在狀態列下方，並在 App Store 的更新選單區顯示「Made for iPhone Duo」標籤；用 iOS 27 SDK 建置的填滿大部分內螢幕，但避開右側狀態列，沒有標籤；iOS 26 以前的置中、兩側留空。10 月 5 日的另一篇 MacRumors 說開發者要用 iOS 27.1 SDK 與 Xcode 27.1，才能讓 App「動態調整大小填滿內螢幕」，沒有提到截止日期。
這件事在設計上的意義是，「適配」從一個主觀描述變成一個可驗證的標籤。標籤的判準是 SDK 版本，不是設計品質：一個把手機版面原樣拉寬的 App，只要用 27.1 重建就能拿到。這是我的推論，MacRumors 只說判準是 SDK；但從判準的寫法看，標籤保證的是「不會黑邊」，不保證「內螢幕有被好好設計」。使用者在商店裡看到標籤，拿到的預期是前者。
三、Apple 示範的好案例，共同點是「利用姿態」
Apple 新聞稿給了幾個具體案例，值得逐一拆。我只讀到新聞稿的摘要，沒有看圖。
Flighty 有「iPhone Duo 立著時」的追蹤航班專用模式。MLB 在半摺放在桌上時，直播在直立的半邊，即時統計放在平放在桌上的半邊。Prime Video 半摺時，影片在上半、X-Ray（演員與花絮資訊）在下半。Zoom 把內螢幕變成視訊會議室，共享內容與其他參與者同時顯示。Word 把格式工具放在文件旁邊，Outlook 把收件匣放在完整郵件旁邊；Fantastical 在大螢幕上並排顯示行事曆、任務與選單。Netflix 在外螢幕滑直式短片，打開後在內螢幕接著看。
把這些放在一起，可以看出兩種模式。一種是「並排」（Word、Outlook、Fantastical、Zoom），把原本要切頁的兩個層級同時放出來，這跟平板上的雙欄沒有本質差別。另一種是「依姿態分區」（MLB、Prime Video、Flighty），半摺時上半放內容、下半放控制或補充資訊，這是只有摺疊裝置才有的設計變數。第二種昨天的評測幾乎沒人提，因為評測多半是在拿著手機的狀態下寫的。這個觀察是我的整理，Apple 的新聞稿是行銷文件，展示的是挑選過的案例，沒有失敗樣本。
從 API 來看，這兩種模式對應到不同的工具。Artem Novichkov 的開源範例庫（MIT 授權，我只讀到 README 摘要，沒有讀程式碼）列出的 iOS 27.1 介面包括：用 onHingeChange 讀鉸鏈角度；從 GeometryProxy 查詢保留區域（折線與相機的位置）；ArrangementView 的 split 樣式（展開時並排、摺起時堆疊）與 overlay 樣式（主要檢視浮在次要內容上，半摺時重新定位）；垂直工具列的溢出與優先順序；以及 contentMargins(for: .container) 處理垂直工具列的邊距。這些名稱來自第三方範例庫的描述，我沒有對照 Apple 文件，昨天整理的 reservedRegions(kind:options:) 與這裡的「查詢保留區域」是同一類東西，但我不確定細節是否對應。
四、NN/g：521 份問卷說 AI 讓 UX 工作變快，但實務者並不開心
NN/g 的 Maria Rosala 與 Rachel Banawa 在 10 月 23 日發表〈AI in UX: Work Is Faster, But Practitioners Have Mixed Feelings〉。方法是 8 月 24 日到 9 月 11 日的線上便利樣本，從 2,814 份提交中留下 521 份完整回答：設計師 246、研究員 145、產品經理 21、其他 109。自算：完整率 18.5%，設計師占 47.2%，產品經理只占 4.0%，所以該文自己也說產品經理樣本偏小。
主要結果：99% 有 AI 工具可用，59% 限定在核准的工具；66% 用過代理式 AI；最常用於寫程式（3.99 分，滿分 5）、桌面研究（3.83）、資料分析（3.81），最少用於訪談（1.82）與使用者測試（1.97）；AI 讓所有任務變短（平均 4.2），程式相關的省時最多，直接面對使用者的最少。態度上，整體平均 3.57 分（略偏正面），但開放留言有 69% 帶負面情緒、41% 純負面；最常見的挫折是輸出不可靠（40 則）、技能退化（26 則）、倫理（25 則）、被要求使用（24 則）。工作保障的自評，設計師 2.99、研究員 2.94，產品經理 3.81。
幾個讀法。第一，「最常用於寫程式」是這份樣本的特色，不代表所有設計師都在寫程式；樣本來自 NN/g 的訂閱者與專業社群，本來就偏向數位活躍的從業者，該文自己列出這個限制。第二，量表是自評，「變快」是感受，不是量測的時間。第三，69% 與 41% 的底數不明：只有 43% 的人留了意見（約 224 人），所以這兩個百分比大概是以留言者為底，不是 521 全部，但摘要沒寫，我不換算成人數，請當作待驗。設計實務上最有用的一組對比是：AI 用得最少的地方是訪談與使用者測試，也就是直接面對使用者的環節；這與 NN/g 10 月 16 日那篇合成受訪者研究（我 10 月 19 日寫過）的結論方向一致，那篇說合成答案的種類比真人少。
五、Smashing：Accordion 圖示該選哪個
Vitaly Friedman 在 10 月 23 日的〈Accordion Icons: Which Work Best?〉把一個常被隨手決定的細節拆開。我讀到的摘要說，這篇引用的是 NN/g 等研究，但沒有給參與人數、方法或百分比，所以結論只能當作設計指引，不能當作量化證據。結論有三點。
其一，沒有圖示時，使用者會預期點下去是直接跳頁，不是展開。其二，自訂圖示讓人猶豫，因為不清楚它會展開，caret（向下的小三角）是最安全的選擇；參與者點文字或點圖示的機率相近，只有 caret 讓人更常點圖示。加減號（+／−）可用，但解讀多種；右向或下向箭頭不會讓人預期跳頁。其三，分裂式選單有害：文字連到一頁、圖示展開子選單，這種設計製造的錯誤比幫助多。建議是預設用向下的 caret、互動後換方向；若是連結就加底線，不加圖示；要避免分裂按鈕，改成讓使用者點主分類就展開選單。
這篇直接指向 iPhone Duo 的右側導覽軌道：一旦導覽元件被搬進窄長的側邊軌道，分類與子選單的展開行為會更頻繁出現，「點文字是跳頁還是展開」的歧義會被放大。這是我的連結，不是文章的內容。
六、一張給今天的檢查表
| 今天讀到的事 | 設計動作 | 驗證方式 |
|---|---|---|
| 標籤判準是 iOS 27.1 SDK | 先拿到標籤，再談設計品質；兩件事分開驗收 | 在 Xcode 27.1 模擬器截內螢幕滿版圖，並單獨列「內螢幕有沒有重新設計」一項 |
| 半摺姿態把內容與控制分到上下兩半 | 影音、通話、追蹤類 App 先決定「上半放什麼、下半放什麼」 | 用鉸鏈角度的測試流程跑半摺狀態，確認按鈕沒有被推到折線 |
| 側邊軌道讓子選單更常展開 | 子選單入口統一為向下的 caret，不做分裂按鈕 | 在原型中找出所有「文字連頁、圖示展開」的地方 |
| 實務者最少用 AI 的地方是訪談與測試 | 設計流程中保留真人測試的時間 | 在專案計畫裡把使用者測試排進行事曆，而不是看 AI 進度 |
🧠 記
- Apple 一手名單： 50 個以上的 App 被點名適配；名單用「包括」開頭，沒被點名不等於沒適配。
- 標籤判準是 SDK，不是設計： 「Made for iPhone Duo」只保證用 iOS 27.1 SDK 建置、內螢幕滿版。
- 兩種好案例： 並排（Word、Outlook、Fantastical）與依半摺姿態分區（MLB、Prime Video、Flighty）。
- NN/g 521 份問卷： AI 讓每項任務變快（平均 4.2），但設計師工作保障自評 2.99；樣本為便利樣本。
- Accordion 圖示： 預設用向下 caret，不做分裂按鈕；Smashing 這篇沒有給量化數字。
- 自算： 完整率 18.5%、設計師占 47.2%、產品經理占 4.0%。
邊界： 本文所有網頁都經網頁抽取摘要，沒有讀完整原文。MacRumors 與 Apple 新聞稿的轉述是摘要，Apple 新聞稿是行銷文件，只展示挑選過的案例。Artem Novichkov 範例庫的 API 名稱是第三方描述，沒有對照 Apple 文件。NN/g 留言百分比的底數不明，我的換算不可靠。Pitre 的評分規則、Apple 設計「What’s new」頁新條目、外內螢幕點數今天都沒能查到。Smashing 這篇的結論沒有量化資料可核對。沒有任何一台 iPhone Duo 在我手上。
✍️ 實踐
用 30 分鐘為你的產品做一次「展開／跳轉」歧義盤點，並對 App 做一次兩階段的 Duo 驗收。
- 在你的導覽與設定頁中，列出所有可展開的項目（accordion、側邊分類、設定群組），記下每一項的圖示是什麼、點文字與點圖示會不會做不同的事。
- 把「文字連頁、圖示展開」的分裂項目挑出來，改成點整列展開、或把連結獨立出來；沒有圖示又會展開的項目補上向下 caret。
- 找 3 位沒看過的人，各給 5 個項目的靜態截圖，問「點這裡會發生什麼」，記錄預期為「跳頁」與「展開」的比例；這是你自己的小樣本，不能外推，但足以判斷哪些項目最歧義。
- 如果有 iOS App：先看自己是不是用 iOS 27.1 SDK 建置，拿到標籤；再另外寫一行「內螢幕是否重新設計」的驗收，分兩欄記錄，不要混成一欄。
- 如果產品有影音、通話、追蹤類功能：在原型上畫出半摺時的上半與下半，決定哪邊放內容、哪邊放控制，並檢查按鈕沒有壓在折線上。
🔗 延伸學習
- Developers bring incredible new app experiences to iPhone Duo（Apple 新聞室） — Apple 對各 App 適配方式的一手說明，我打開並抽取過，行銷文件性質。
- Apple Will Label Apps ‘Made for iPhone Duo’ in App Store（MacRumors） — 標籤判準與三階 SDK 的整理，我打開過。
- AI in UX: Work Is Faster, But Practitioners Have Mixed Feelings（NN/g） — 10 月 23 日問卷，可看樣本限制與各項數字，我打開過。
- Accordion Icons: Which Work Best?（Smashing Magazine） — 10 月 23 日，展開類圖示的選擇指引，我打開過。
💬 問 AI
我想為「iPhone Duo 的 App 適配」與「展開類介面元件的圖示選擇」做一次設計盤點。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、版本號、數字或引文,也不要給任何投資或財務建議。
背景(請當待查證主張):
1. Apple 在 2026-10-22 的新聞稿與 MacRumors 整理中點名 50 個以上適配 iPhone Duo 的 App(含 Netflix、Prime Video、MLB、Zoom、Slack、Instagram、Word、Outlook、Flighty、Fantastical、Things、Bear);App Store 會替用 iOS 27.1 SDK 以上建置的 App 標上「Made for iPhone Duo」;iOS 27 SDK 的 App 填滿大部分內螢幕但避開右側狀態列;iOS 26 以前的置中留空。
2. Apple 示範案例包含半摺姿態分區:MLB 直播在直立半邊、統計在平放半邊;Prime Video 影片在上半、X-Ray 在下半。
3. NN/g 在 2026-10-23 發表 AI in UX 問卷:2,814 份提交中 521 份完整、設計師 246;99% 可用 AI;66% 用過代理式 AI;AI 讓任務變快平均 4.2/5;設計師工作保障自評 2.99;開放留言 69% 帶負面情緒。我自算完整率 18.5%、設計師占 47.2%。
4. Smashing(2026-10-23)稱展開類圖示以向下 caret 最安全、分裂式選單(文字連頁、圖示展開)有害,但摘要中沒有參與人數或百分比。
5. 我讀到 W3C WCAG 3 編輯草稿(2026-10-07)的文字對比判準仍是「待決定」,Apple 設計 What's new 頁最新條目我只確認到 2026-10-13。
請做:
A. 逐點驗證 1 到 5,標示「成立/部分成立/查不到」並附一手連結;特別確認 Apple 是否已公布外螢幕與內螢幕的點數、「Made for iPhone Duo」的判準是否只有 SDK 版本。
B. 查 Smashing 該文所引的研究原始出處與樣本數;若查不到,說明哪些結論只能當作設計指引、不能當作量化證據。
C. 我的 App 有側邊導覽軌道與可展開的設定群組:列出最可能造成「點文字還是點圖示」歧義的 5 個位置,各附「不靠肉眼」的檢查方式(例如可用 UI 測試腳本抓哪些屬性)。
D. 設計一個 5 分鐘流程,在半摺姿態下檢查影音或通話類畫面的按鈕有沒有被折線與保留區域壓到。
不要評論公司或人事,只談設計實務、量測方法與證據強度。