Icon Composer 圖示怎麼接入 Xcode 27？2026 驗收清單

接入失敗通常不是設計檔壞掉，而是把不同用途的檔案混為一談。你需要分開檢查以下資源：

• 設計來源檔：分層 SVG 或 PNG，保存圖層、材質與可調整內容。它是設計工作檔，不代表一定會進入 App Bundle。
• Icon Composer 檔案：負責組合分層圖示、外觀變體與平台呈現。它需要被加入正確的 Xcode Target。
• AppIcon 資產目錄：傳統圖示資產。即使專案加入 Icon Composer，也不要假設它會自動消失或永遠不再被使用。
• App Bundle 內的圖示資源：真正隨建置產物交付的內容。編輯器預覽正常，不等於安裝後讀到的就是這份資源。
• 行銷用扁平圖：App Store 展示素材，與 App 安裝後桌面圖示的責任不同。不能用商店圖片代替裝置驗收。

Apple 說明 Icon Composer 可建立面向多平台與多種外觀的分層圖示，但這不表示同一組圖層在 iPhone、iPad、Mac 與 Apple Watch 上必然有相同的辨識度。平台遮罩、裁切比例和明暗外觀都要個別看結果。

新建的 iOS 或 macOS App 沒有歷史圖示包袱時，直接採用 Icon Composer 通常是較乾淨的方案。先建立獨立的 Git 分支，即使是新專案也不要把設計、專案設定和發布驗收混在同一次提交中。

素材與 Target 關聯

1. 準備分層 SVG 或 PNG。每一層使用可辨識的名稱，避免以 Layer 1、Layer 2 這類無法追蹤用途的名稱交付。
2. 建立 Icon Composer 檔案，確認前景、背景、陰影或其他視覺層級沒有被合併成單一扁平圖片。
3. 將檔案加入 Xcode 專案，並檢查 Target Membership。檔案出現在 Project Navigator，不代表它會被目標建置使用。
4. 檢查 Target 的 App Icon 設定，確認名稱與實際 Icon Composer 資源一致。檔名不同、設定仍指向舊 AppIcon，是最常見的「已匯入但建置沒變」原因。
5. 先建置並安裝到 Simulator，再看桌面圖示與 App 內顯示結果。不要只看 Icon Composer 編輯器中的預覽。
6. 分別檢查 Default、Dark 和 Mono 外觀。每種外觀都要在實際安裝結果中可辨識，而不是只確認檔案能成功編譯。

Icon Composer 檔案怎麼加入現有 Xcode 專案？
重點不是把檔案拖進 Navigator，而是完成三個關聯：檔案納入版本控制、檔案加入正確 Target、Target 的 App Icon 設定指向它。完成後，應從 Archive 產物反向確認資源，而不是以 Xcode 左側檔案樹作為唯一證據。Apple 的 圖示配置說明 可用來核對專案設定位置。

已有 AppIcon 的專案不能用「預覽看起來正常」作為切換條件。Icon Composer 檔案可能改變原有圖示資產的取用關係，直接刪除 AppIcon 會讓回退成本上升，也可能讓低版本系統出現與新系統不同的渲染結果。

用了 Icon Composer 後還能保留舊 AppIcon 嗎？
可以先保留，但要把它視為有條件的雙軌驗證，而不是永久同時輸出。你應在獨立升級分支保留舊資源，明確記錄哪個 Target 使用哪組圖示，再比較繼續沿用 AppIcon 與切換 Icon Composer 的差異。只有當新舊系統、實際安裝和分發建置都通過，才考慮刪除舊資源。

建議用以下決策順序：

• 如果是新 App，沒有既有桌面圖示和回溯需求：採用 Icon Composer，直接建立四層驗收紀錄。
• 如果是存量 App，且舊圖示仍是品牌識別的一部分：保留 AppIcon，先比較兩條路徑，不要以檔案數量作為刪除理由。
• 如果新外觀只在新系統有意義，但舊系統需要維持原樣：保留回退提交，針對最低部署版本的真機或模擬器留下截圖。
• 如果專案同時有多個 App Target：逐一確認 Bundle Identifier、Target Membership 和圖示設定，不能只測試主 App。

為什麼 Icon Composer 圖示在較低版本 iOS 上會顯示不同？
不同系統可能採用不同的圖示處理、遮罩或可用外觀。任務書未確認 Xcode 27 正式版對所有版本的最終行為，因此不要自行推斷相容性。實務上應把最低部署版本列為獨立驗收項目，記錄實際安裝畫面；若結果不可接受，回退到原有 AppIcon，而不是單純清除快取後重試。

注意：設計來源檔、Icon Composer 檔案、AppIcon、Bundle 資源和 App Store 行銷素材必須分開命名與歸檔。它們用途不同，不能用其中一項證明其他項目正確。

同一個分層設計可以共享，但不代表每個平台都應該完全不調整。iPhone 與 iPad 的圖示辨識距離、Mac 的顯示形狀，以及 Apple Watch 的可視範圍都可能不同。

對同時支援多平台的專案，請把問題拆成兩層：

• 共享層結構：確認品牌主體、背景和主要對比關係能由同一套分層來源管理。
• 平台差異化：允許針對遮罩、留白、文字可讀性和細節密度做平台調整。為了維持單一檔案而犧牲某一平台的辨識度，並不是成功的共享設計。

Default、Dark 和 Mono 也要各自驗收。你需要在淺色、深色及常用輔助顯示設定下確認輪廓、前景對比和細節是否仍然清楚。這裡不延伸到整個介面的 Liquid Glass 測試；本文只處理圖示資源及其發布結果。

使用遠端 Mac 時，問題常出在環境差異，而不是圖示本身。Apple 官方下載頁目前要求獨立下載版本的 Icon Composer 執行於 macOS Tahoe 26.4 或更高版本，應以 Icon Composer 官方系統要求 作為環境檢查依據。

遠端 Mac 建置時找不到 Icon Composer 檔案怎麼辦？
先不要清空所有快取。依序確認檔案是否被版本控制、同步腳本是否包含該副檔名、建置工作目錄是否正確，以及 Target Membership 是否在非互動式環境中仍然有效。然後保存 actool、ibtool 和 Archive 日誌，從錯誤發生的階段判斷是資源同步、編譯設定還是封裝問題。

你可以按以下順序操作：

1. 在遠端 Mac 確認 macOS、Xcode 和 Icon Composer 工具鏈符合官方要求。不要只看登入畫面顯示的 Xcode 名稱。
2. 從版本控制重新取出專案，檢查 .icon 檔案是否真的存在於工作目錄。不要依賴上一次工作階段留下的未追蹤檔案。
3. 檢查同步腳本、忽略規則與檔案權限，確認 Icon Composer 資源沒有被排除。
4. 在 Xcode 中核對 Target Membership、Asset Catalog 和 App Icon 設定，確保自動打包使用的 Target 與本地測試相同。
5. 以命令列執行 Archive，保留完整輸出、建置設定和失敗時間點。非互動式建置成功，才代表持續整合流程有基本可重現性。
6. 從 .xcarchive 和最終 App Bundle 檢查圖示資源，再把建置上傳到 TestFlight。不要以成功產生 Archive 檔案取代安裝驗收。
7. 若失敗，先比較檔案清單、Target 設定與工具鏈版本，再決定是否清理特定快取。全面清理會掩蓋真正的同步或設定錯誤。

如需讓遠端 Mac 作為固定的 iOS 打包伺服器，可先閱讀 遠端 Mac 的建置驗收方案，再決定是否需要長期保留環境。若只是一次遷移或短期多版本測試，按需租用 Mac 的方案說明會比先購買專用硬體更容易控制試錯成本。

發布負責人應把編輯器預覽、桌面圖示和商店素材視為三個不同畫面。以下清單必須在合併移除舊 AppIcon 前完成：

• [ ] 專案設定中的 Target、Bundle Identifier 和 App Icon 名稱已核對。
• [ ] Icon Composer 檔案已納入版本控制，且在乾淨工作目錄可重新取得。
• [ ] Simulator 已安裝建置，Default、Dark、Mono 外觀均有實際截圖。
• [ ] 真機已安裝建置，最低部署版本與主要支援裝置均完成檢查。
• [ ] 多平台 Target 已分別檢查遮罩、留白、細節密度和辨識度。
• [ ] Archive 產物已檢查，確認 Bundle 內不是舊資源或錯誤 Target 的圖示。
• [ ] TestFlight 建置已成功處理，並在實際安裝後再次確認桌面圖示。
• [ ] App Store 展示用扁平圖與安裝後圖示已分開核對。
• [ ] 建置日誌、截圖、版本控制提交和回退條件已保存。
• [ ] 所有不可接受的視覺偏差都有明確處理方式：修正、保留舊 AppIcon 或回退。

Icon Composer 圖示送交 App Store 前要檢查哪些內容？
至少要確認 Archive 產物、TestFlight 實際安裝結果和商店展示素材三者沒有混淆。上傳狀態也要看 App Store Connect 的處理結果；Apple 的建置上傳狀態說明可協助你區分上傳完成與建置已被正確處理。只有處理成功且關鍵裝置驗收通過，才適合結束雙軌維護。

對獨立開發者而言，本地 Mac 直接測試的優點是互動快速；缺點是容易遺漏乾淨環境、非互動式 Archive 和跨版本回退。遠端 Mac 的價值不在於把所有工作搬到雲端，而在於提供可重建的獨立分支和持續在線的打包環境。若本地 Mac 無法安裝符合要求的工具鏈，或你不想為一次遷移長期保留多套測試環境，CALMVPS 的 Mac 租用可讓你先建立隔離環境，完成 Archive 與 TestFlight 驗收後，再決定是否需要常駐伺服器。若你的工作是長期穩定重負載、必須連接實體裝置或需要完全掌控硬體，直接自購 Mac 仍可能更合適；租用的優勢主要在短期遷移、版本驗證和臨時 iOS 打包。

把舊 AppIcon 留在回退分支，並以四層真實建置結果作為切換門檻。這比單看 Icon Composer 預覽更能避免圖示在 TestFlight 或商店流程中突然回到舊版本。