HomeView 的第三方 App 怎麼上螢幕，今天有了一手答案，而且答案不是「給設計師一塊 1088 × 1088 的畫布」。Apple 在 10 月 13 日改版的《CarPlay Developer Guide》（70 頁 PDF，頁尾日期 2026-10-13）第 5 頁與第 13 頁各有一句：「CarPlay 的音訊與影片 App 也能在 Apple HomeView 上運作，不需要你對 App 做任何修改」；第 13 頁同一段還寫，App 透過 CarPlay 框架提交 UI 元素，由 iOS 負責顯示，App「不需要處理不同螢幕解析度的版面」。我是下載 PDF 後逐頁搜尋「HomeView」，整份文件只出現三處（第 5、13、15 頁），都在這個脈絡裡。換句話說，音訊與影片類 App 在這台螢幕上的版面，是 Apple 的範本決定的，不是各 App 自己排的。
這讓 昨天的 UIUX 那條「字級與距離」的推算多了一層前提：它適用的是 Apple 自己的畫面（face、內建 App），不一定適用於第三方。今天把兩件事做完：先把這份指南的原文和評論界對方形螢幕的批評放到同一張表，再用 1088 × 1088 與 220 ppi 把「方形放影片、放食譜」算成具體的像素與字數。昨天預留的實機驗證要等 11 月 13 日出貨，今天沒有新資料，維持待驗。
📖 學
一、一手文件說了什麼，沒說什麼
| 項目 | 文件原意 | 我的讀法 |
|---|---|---|
| 哪些 App 會出現 | 第 15 頁註腳：持有 CarPlay audio（CarPlay framework）或 CarPlay video entitlement 的 App 會出現在 HomeView | 資格是「已經是 CarPlay 的 App」，不是新的 HomeView 計畫 |
| 要不要改 | 「不需要做任何修改」 | 沒有 HomeView 專屬版面可調 |
| 誰排版 | 第 13 頁：UI 元素由 CarPlay 框架提交，iOS 管顯示，不用處理不同解析度，也不用支援觸控、旋鈕等不同輸入 | 設計師能控制的是資料（標題、封面、清單結構），不是像素 |
| 規則 | 第 6 頁：範本只能用在原本用途（清單範本用來呈現可選清單、播放畫面的圖只能放專輯封面） | 版面創意的空間本來就被規則鎖住 |
| 影片 App | 第 9 頁：必須主要提供影片播放，且必須支援 AirPlay 影片串流 | 影片的畫面比例仍是影片自己的，範本沒有說會被裁切 |
| 歌詞 | 第 6 頁：「不得在 CarPlay 螢幕顯示歌詞」；Apple 新聞稿卻說 HomeView 上的 Apple Music 有動態封面與歌詞 | 兩者不矛盾的解釋是：Apple Music 是內建 App，不受該指南約束；但這規則在 HomeView 上對第三方是否放寬，文件沒說，我查不到 |
沒說的事同樣重要。第三方開發者 Blake Crosley 在發表當天整理，稱 Xcode 27.2 beta 1 沒有 HomeView 平台或模擬器、《人機介面指南》（HIG）沒有 HomeView 條目、Apple 從未文件化點數、比例或與距離相關的 API，並稱當天下午 Apple 更新了開發者計畫授權協議第 6.4.2 條，說明這些 App 會在「搭配的 iOS 裝置執行時」出現在 HomeView。這些是他的整理，我沒有去讀授權協議全文。我自己能驗的只有兩件：我猜的 HIG 網址 /homeview 回傳 404（這只能證明那個網址不存在，不能證明沒有條目，因為 HIG 是前端渲染的頁面，我抓不到導覽內容）；以及上面那份 PDF。所以「HIG 尚無 HomeView 條目」目前是第三方說法加我一個弱證據，不是我確認過的事實。
這裡有一個值得留意的邏輯：Apple 的做法是讓既有的 CarPlay 範本直接上新硬體。這是工程上最省力的路，但對設計意味著：HomeView 上的第三方畫面會繼承「開車情境」的設計約束，也就是少文字、大目標、不顯示訊息內容；用在廚房牆面或床頭，是否合適，要看實機。這是我的推論，文件沒有這樣說。
二、評論界的批評，和一個可以算的版本
MacDailyNews 在發表當天有一篇措辭很重的評論（它是 Apple 立場鮮明的評論站，我把它當批評意見，不當事實來源）。與設計相關的兩點是：方形螢幕對影片、群組 FaceTime 與食譜步驟會造成「彆扭的裁切或捲動」；以及發表影片裡的人常常湊近螢幕看。這兩點都可以用規格頁的數字換成量，而不必靠形容詞。
先算影片。螢幕寬 1088 px、像素間距 25.4 ÷ 220 = 0.1155 mm，可視邊長 125.6 mm（昨天已驗算）。影片依寬度鋪滿（不裁切）時：
| 影片比例 | 影片像素 | 實際尺寸 | 影片對角線 | 佔螢幕面積 | 上下（或左右）黑邊各 |
|---|---|---|---|---|---|
| 1:1 | 1088 × 1088 | 125.6 × 125.6 mm | 6.99 吋 | 100% | 0 |
| 4:3 | 1088 × 816 | 125.6 × 94.2 mm | 6.18 吋 | 75.0% | 136 px（15.7 mm） |
| 16:10 | 1088 × 680 | 125.6 × 78.5 mm | 5.83 吋 | 62.5% | 204 px（23.6 mm） |
| 16:9 | 1088 × 612 | 125.6 × 70.7 mm | 5.67 吋 | 56.3% | 238 px（27.5 mm） |
| 2.39:1 | 1088 × 455 | 125.6 × 52.6 mm | 5.36 吋 | 41.8% | 316 px（36.5 mm） |
| 9:16 直式 | 612 × 1088 | 70.7 × 125.6 mm | 5.67 吋 | 56.3% | 左右各 238 px |
算式很簡單：影片高 = 1088 × 比例的短邊 ÷ 長邊，面積占比 = 影片面積 ÷ 1088²。最常見的 16:9 影片只用到 56.3% 的面積。換一個比較基準：同樣是「7 吋」，一台 16:9 的 7 吋螢幕是 155.0 × 87.2 mm（面積 13,508 mm²），HomeView 上播 16:9 影片的畫面是 125.6 × 70.7 mm（8,876 mm²），只有前者的 65.7%。也就是說，同一個 7 吋標稱，拿來看影片只有一般橫式 7 吋的三分之二。這是純幾何，不依賴任何假設。
若選擇「填滿」而不是「完整」，16:9 影片的可見寬度只剩 1088 ÷ (1088 × 16 ÷ 9) = 56.25%，也就是左右各砍掉 21.9%。電影的 2.39:1 更慘：填滿時只剩約 41.8% 的寬度。所以「彆扭的裁切」這個批評，在算式上是成立的；它是不是「彆扭到無法接受」則是主觀判斷，我不下結論。
三、黑邊不是浪費，是版面
16:9 影片留下的上下各 238 px 黑邊，不用白白空著。拿昨天的視角基準（0.403 度，我的假設）換算：2 公尺處的 em 是 121.8 px，一條黑邊高 238 px = 1.95 em，剛好放一行字幕（含 1.5 倍行距要 1.3 em）；1 公尺處 em 是 60.9 px，一條黑邊是 3.9 em，可以放兩行字幕加一個進度列。所以對影片播放介面，合理的做法是把字幕、標題和控制元件全部放進黑邊，影片本體不被遮住。這是我的設計建議，前提是影片是 16:9 並完整顯示；若 App 把字幕燒進畫面，這個空間用不到。
四、食譜：容量與距離平方成反比
Apple 說 HomeView 能把網路上的食譜轉成逐步指示，並有免持計時。食譜的字量是個好測試，因為它是大段文字、需要在站著煮菜時讀。沿用昨天的基準與公式，單頁最多容納的全形字數是 (1088 ÷ em)² ÷ 行距，這裡行距取 1.5，並且假設整個螢幕只放正文、沒有任何邊距與按鈕，所以是上限：
| 觀看距離 | 0.403 度：em（px） | 一頁容量（字） | 0.3 度：em（px） | 一頁容量（字） |
|---|---|---|---|---|
| 0.5 公尺 | 30.5 | 35.7 × 23.8 = 850 | 22.7 | 48.0 × 32.0 = 1,535 |
| 1 公尺 | 60.9 | 17.9 × 11.9 = 213 | 45.4 | 24.0 × 16.0 = 384 |
| 2 公尺 | 121.8 | 8.9 × 5.95 = 53 | 90.7 | 12.0 × 8.0 = 96 |
| 3 公尺 | 182.8 | 6.0 × 3.97 = 24 | 136.1 | 8.0 × 5.33 = 43 |
每把距離加倍，容量縮成四分之一，這是 (距離)² 的必然結果。一則假設的食譜步驟「洋蔥切丁，放入預熱好的鍋中以中火炒到半透明約五分鐘，再加入蒜末」約 50 個全形字（我自己寫的長度，不是 Apple 的範例）。在 2 公尺、0.403 度下，一頁容量是 53 字，也就是一個步驟就把整個螢幕佔滿、沒有空間放計時器或按鈕；同樣步驟在 1 公尺是 213 字，一頁放得下四步。
這也說明為什麼「依距離切換」不是裝飾。遠距離只能顯示一句話級的資訊（單步、大計時器），近距離才有容量顯示整份食材清單。MacDailyNews 提到的「演員要湊近看」，在這個模型裡是可以預期的：要讀多於 50 字的內容，就得把距離縮到 1 公尺內。這是模型與評論的吻合，不是證明；我沒看到 Apple 的設計文件，也不知道食譜畫面實際的字級。
五、群組 FaceTime：四個人最多佔六成
Apple 新聞稿稱 FaceTime 搭配 Center Stage，讓每個人「在走動時也能完整入鏡」。群組通話的格子數與比例沒有公布。如果四個人用 2 × 2、每格 16:9：每格 544 × 306 px（62.8 × 35.3 mm），四格合起來只佔 1088 × 612，也就是 56.3% 的面積，其餘是兩條各 238 px 的空白；若改把每格裁成方形 544 × 544，則 100% 利用，但每格影像會損失約 44% 的寬度（假設原始是 16:9）。九人時 3 × 3，每格 362.7 px，16:9 時高 204 px。
至於 Center Stage 輸出的比例，Apple 沒有說。這是整段最大的未知數，所以上面的數字是「如果」，不是預測。
六、這整件事對一般設計的啟示
可以帶走的有三個。第一，先算最壞比例，再設計：這台螢幕的 1:1 對任何橫式影片都是 56% 起跳的面積，若你的產品也有這種比例極端的容器（嵌入式小螢幕、車機、手錶），先列出會進來的內容比例，算每一種的面積占比，才知道哪一個是痛點。第二，黑邊是版面資源：16:9 影片的 238 px 上下邊在 1 公尺距離能放兩行字幕加控制列，浪費才是設計沒有分配。第三，範本制度下，設計師的槓桿是資料：如果版面由框架決定，要做的是封面圖的裁切安全區、標題長度（遠距離約 4 到 9 字，見昨天的算式）與清單層級，而不是像素微調。
🧠 記
- 一手文件： 《CarPlay Developer Guide》2026-10-13 版，第 5、13 頁：CarPlay 音訊與影片 App 不需修改即可在 HomeView 運作；第 13 頁：iOS 管顯示、App 不處理不同解析度；第 15 頁註腳：持有 audio 或 video entitlement 的 App 會出現。
- 影片： 1088 px 寬，16:9 為 1088 × 612，佔 56.3%、黑邊各 238 px（27.5 mm）；2.39:1 佔 41.8%；比同樣標稱 7 吋的 16:9 螢幕少 34.3% 面積（65.7% 對 100%）。
- 填滿： 16:9 可見寬度 56.25%，2.39:1 約 41.8%。
- 食譜容量上限（0.403 度、行距 1.5）： 0.5 公尺約 850 字、1 公尺約 213 字、2 公尺約 53 字、3 公尺約 24 字；每加倍距離容量除以 4。
- 黑邊字幕： 2 公尺 1.95 em，1 公尺 3.9 em。
- 仍未回答： 距離切換的臨界與遲滯、近看字級、兩人並排顯示、HIG 是否有條目、第三方 App 歌詞規則是否放寬。
邊界： CarPlay 指南的引用來自我下載的 PDF 文字抽取，我沒有逐頁看排版圖；「HIG 沒有條目」「授權協議第 6.4.2 條內容」「Xcode 27.2 beta 沒有 HomeView」都是 Blake Crosley 的整理，我只驗證了 /homeview 網址 404；視角基準 0.403 度與 0.3 度、行距 1.5、整頁只放正文都是假設，食譜容量是理論上限，實際會因邊距與計時器少一半以上；50 字的食譜步驟是我自己寫的長度；2 × 2 與 3 × 3 群組通話版型、Center Stage 的輸出比例全是假設；MacDailyNews 是意見來源；昨天的三條預測（遠看字高 4.2% 到 11.2% 邊長、近看 2.1% 到 2.8%、比值）要等 11 月 13 日之後的實機畫面才能驗證，今天沒有新資料。
✍️ 實踐
用 15 到 20 分鐘，為你的產品算一次「容器比例對內容比例」的面積表，並找出能放東西的黑邊。
- 列出你的介面裡出現的容器（例如 1:1 的小螢幕、手機直式、車機），以及會放進去的內容比例（16:9 影片、4:3 照片、1:1 縮圖、9:16 限時動態）。
- 貼進下面這段程式，換成你的數字，輸出面積占比與黑邊像素。
function fit(containerW, containerH, a, b) {
// 內容比例 a:b，完整顯示（不裁切）
const scale = Math.min(containerW / a, containerH / b);
const w = a * scale, h = b * scale;
return {
w: Math.round(w), h: Math.round(h),
areaPct: +(w * h / (containerW * containerH) * 100).toFixed(1),
barX: Math.round((containerW - w) / 2),
barY: Math.round((containerH - h) / 2),
};
}
console.log(fit(1088, 1088, 16, 9)); // 預期 w=1088 h=612 areaPct=56.3 barY=238
console.log(fit(1088, 1088, 2.39, 1)); // 預期 h=455 areaPct=41.8 barY=316- 先用 HomeView 的 1088 × 1088 驗證輸出與上面表格相同，再換成你的容器。
- 對每一組，把黑邊高除以你的最小正文字高（像素），看能放幾行字、幾個控制元件；字高可用昨天的公式從設計距離反推。
- 找出面積占比最低的組合，決定它是否需要專屬版面（例如影片改填滿加燒入字幕）或者接受黑邊，並把結論寫進設計規範。
🔗 延伸學習
- CarPlay Developer Guide（Apple Developer） — 2026-10-13 版，第 5、13、15 頁有 HomeView 的原文；第 6、9 頁是音訊與影片 App 的規則。PDF 約 25 MB。
- Meet Apple HomeView, a new way to enjoy entertainment and manage the home（Apple Newsroom） — FaceTime 與 Center Stage、食譜、Apple Music 歌詞與動態封面的原文。
- Apple HomeView for Developers: What Apple Said on Day One（Blake Crosley） — 第三方整理發表當天開發者端沒公布的事，含授權協議第 6.4.2 條的說法；未經我逐項核對。
- Apple’s HomeView launch video is a spectacular disaster on many levels（MacDailyNews） — 對方形螢幕與發表影片的批評意見，立場鮮明，當意見讀。
💬 問 AI
我想把「方形螢幕放影片與長文字」做成可驗算的設計決策,以 Apple HomeView 為例。請嚴格分成「文件明說」「你查證到的」「你的推論」三區回答,不確定就直說,不要編造連結、數字、版本號或引文。
背景(請當待查證主張):
1. Apple 規格頁:HomeView 7 吋方形,1088 x 1088,220 ppi,可視邊長 125.6 mm,像素間距 0.1155 mm。
2. Apple CarPlay Developer Guide(2026-10-13 版)第 5、13 頁:CarPlay 音訊與影片 App 在 HomeView 上不需修改;iOS 負責顯示、App 不需處理不同螢幕解析度。第 6 頁規定 CarPlay 音訊 App 不得顯示歌詞。
3. 16:9 影片完整顯示:1088 x 612,佔面積 56.3%,上下黑邊各 238 px(27.5 mm);2.39:1 佔 41.8%。
4. 視角基準(我的假設):0.403 度與 0.3 度;1.5 倍行距下整頁容量 = (1088/em)^2 / 1.5。2 公尺時 em 為 121.8 px 或 90.7 px,容量約 53 或 96 個全形字。
請做:
A. 逐點驗證 1 到 3,標示「成立/部分成立/查不到」並附一手連結;特別確認 Apple 是否公布 HomeView 的點(pt)比例、HIG 是否有 HomeView 條目、第三方 App 的歌詞規則是否在 HomeView 上放寬。
B. 查至少兩份關於遠距離閱讀、視角與字高的標準或實證研究(例如 ISO 9241、人因研究),比較我用的 0.403 度與 0.3 度。
C. 對 4:3、16:10、16:9、2.39:1、9:16 內容,在 1088 x 1088 上各算面積占比、黑邊像素,並建議黑邊該放哪些元素(字幕、控制、標題)。
D. 若群組視訊用 2 x 2 與 3 x 3 格,在 16:9 與裁成方形兩種策略下各算每格像素與面積利用率,並說明需要實機量測的假設。
不要評論公司財務或產品好壞,只談尺寸、人因證據與實作。