Archive 或 IPA 看起來很大，但你不確定使用者實際會下載多少。
最快解法：本週先用 Xcode 27 匯出 App Thinning Size Report，再到 App Store Connect 核對裝置變體；不要把 Archive 或上傳用 IPA 的檔案大小直接當成 App Store 下載大小。這就是 Xcode 27 iOS App 體積優化的第一個判斷。
準備提交新版本、發現體積明顯增加的獨立 iOS 開發者，先看懂上傳產物與使用者下載量的差別。
維護多種裝置變體或多語系資源的團隊，可用報告定位可精簡內容。
若你需要反覆 Archive 和匯出驗收，還應固定構建條件，讓不同版本可以比較。
先分清楚你量到的是哪一種體積
「App 大小」不是單一數字。Archive 是 Xcode 的封存產物；IPA 是匯出或上傳用的封裝檔；使用者下載的變體則會依裝置取得相應內容。安裝後占用空間又是另一個指標，不能拿某個本地檔案大小代替全部答案。
| 測量對象 | 代表什麼 | 證據入口 | 你接下來要做什麼 |
|---|---|---|---|
| Archive | Xcode 封存的構建產物，不等於使用者下載量 | Organizer 的封存項目 | 用於檢查構建與匯出，不直接判定下載體積 |
| IPA | 匯出或上傳用的封裝檔 | 匯出檔案與構建設定 | 生成 App Thinning Size Report，再核對裝置變體 |
| 變體下載大小 | 特定裝置預計取得的 App 內容 | App Store Connect 構建資訊 | 按目標裝置檢查發布影響 |
| 安裝後占用 | 安裝完成後 App 在裝置上占用的空間 | App Store Connect 大小資訊及裝置實際狀態 | 與下載大小分開評估 |
Apple 的應用程式大小測量與 App Thinning Size Report 說明提供產生報告的官方流程，也提醒 App Store Connect 的應用程式大小資訊更適合用來確認實際發布結果。不要把「本機看到的檔案較大」直接翻譯成「每位使用者都會下載同樣多的資料」。
第一步：匯出報告並保留比較條件
先對準備提交的構建執行 Archive。接著在 Organizer 選取該封存項目，按分發或匯出流程產生包含 App Thinning Size Report 的產物。實際操作時，確認你匯出的是預定發布的組態，而不是 Debug 構建或另一個尚未驗收的版本。
報告要和構建版本、匯出選項及專案提交狀態一起保存。否則，下次看到大小變化時，你很難分辨變動來自程式碼、資源，還是兩次匯出條件不同。
| 報告中要比對的指標 | 可能指出的方向 | 下一步 |
|---|---|---|
| 通用版本與裝置變體 | 資源或二進位檔是否按裝置裁切 | 到 App Store Connect 核對對應裝置類型 |
| 資源相關項目 | 圖片、音訊、影片或其他素材的交付量 | 找出首次安裝不需要的內容 |
| 可執行檔與嵌入框架 | 程式碼或第三方框架可能增加 | 檢查實際嵌入項目及 Release 設定 |
| 下載與安裝資訊 | 下載量和安裝占用可能不同 | 分別按發布提示及裝置使用情境評估 |
資源指標：先查首次安裝真的需要的內容
如果報告顯示資源是主要來源，先查 Asset Catalog、圖片、字型、音訊及影片等目錄。常見的隱性成本不是單一圖片太大，而是相同素材以不同尺寸或格式重複收錄，或首次安裝就帶入只有特定功能才會用到的內容。
Apple 說明 Asset Catalog 如何管理資源變體。這類變體機制可讓系統依目標裝置選取合適資源，但前提是素材正確整理、設定並由建置流程處理。檢查資源時，不要只看來源檔案；要以報告中的裝置變體結果確認交付內容。
若影片、關卡素材或大型離線資料不是首次啟動所需，可評估按需提供；若使用者離線時必須立即使用，延後下載可能反而損害核心體驗。Apple 的進階大小最佳化文件列出資源壓縮與按需資源等方向，但沒有一種方法適用所有 App。
場景案例：你的 App 加入新手教學影片後，整體匯出檔變大。先在報告中確認影片是否進入各裝置變體，再判斷它是否必須隨首次安裝提供。若使用者完成新手流程後仍需離線播放，延後交付未必合適；若它是可重複下載的選配內容，才值得測試按需交付。
優點與代價：
- 精簡重複或不必要素材，能直接針對實際交付內容處理。
- 將內容改為按需提供，可能降低初次下載量，但會增加網路依賴與內容管理工作。
- 單純壓縮圖片或媒體也可能影響畫質；每次調整都要以產品可接受的品質驗收。
二進位檔指標：把程式碼與診斷檔案分開
若報告把主要增量指向可執行檔或嵌入框架，先檢查 Release 構建實際帶入哪些程式碼和框架。留意不再使用的依賴是否仍被嵌入、不同 Target 是否重複包含內容，以及構建設定是否符合發布用途。
Apple 的建置設定參考可用來確認最佳化相關設定；設定檢視時，應查看目標實際生效的值，而非只憑專案檔中某一處的文字判斷。Apple 亦說明如何檢視 Target 的最終建置設定。
另外，dSYM 等符號檔是診斷用途，不應把整份 Archive 連同這些檔案的大小直接當成使用者下載量。先看報告與 App Store Connect 的變體資料，再確認符號檔是否屬於所比較的產物。此處要找的是隨 App 分發的內容，不是封存目錄裡所有檔案的總和。
04裝置變體指標：確認 App Thinning 是否改變結果
通用版本與裝置變體可能包含不同的資源組合。若你只看一份本地 IPA，就可能忽略不同裝置取得的內容差異。多語系 App 也要檢查語言資源是否依預期提供；不要只用開發者自己的裝置推斷所有使用者的結果。
完成本地報告後，到 App Store Connect 對應構建頁查看大小資訊。Apple 的構建版本與中繼資料說明指出可以檢視構建及 App 大小相關資料；這是發布前核對的重要依據。若頁面尚未顯示完整資料，先確認構建處理狀態，避免拿未完成的結果與本地報告硬比。
不要把 App Store Connect 顯示的大小，和 Apple 提供的各平台構建檔案上限混為一談。前者用於理解交付大小，後者是上傳限制，兩者回答的是不同問題。
05下載體驗指標：依發布提示決定先改什麼
Apple 文件提及 200 MB 蜂巢網路下載限制相關條件，但實際下載行為還會受使用者裝置設定與系統提示影響；應以Apple 的應用程式大小說明及目標裝置上的實際狀況核對，而不是把門檻當成所有使用者都相同的硬性結果。超過相關條件時，部分使用者可能需要改用 Wi‑Fi 或調整下載選項。
Apple 的構建檔案上限頁也列出 4 GB 的 iOS App 檔案上限；這是上傳端界線，不表示 App 接近上限才需要最佳化，更不是使用者下載量的估算值。請直接在Apple 構建檔案大小上限說明確認適用平台與規則。
使用以下條件決定優先順序：
- 若 App Store Connect 的目標裝置變體已符合下載情境，而且安裝占用也可接受，就先接受現狀，留存報告作為下一版基準。
- 若變體大小超出你設定的發布目標，回到報告定位資源、二進位檔或裝置變體，再針對主要來源修改。
- 若下載大小可接受但安裝後占用仍造成問題，優先檢查安裝內容與功能所需資源，不要只追求 IPA 檔案變小。
- 若主要增量來自首次安裝不需要的內容，才評估按需交付；若核心流程依賴離線可用，保留必要內容並尋找其他可驗證的精簡點。
重複構建指標：把大小變化變成可比較的資料
若每次 Archive 都更換組態、匯出選項或資源版本，報告就無法公平比較。建議固定專案提交版本、發布組態、匯出流程與報告留存位置；每次提交前產生同類報告，並記錄變體下載大小、安裝占用及主要資源或二進位檔變化。
如果你目前的 Mac 硬碟空間或使用時段不足以穩定完成重複驗收，可以先了解遠端 Mac 的 Xcode 使用方式。遠端環境是否合適，仍取決於你是否能固定專案版本、保存產物並安全管理簽署資料；它不會自動替你完成體積回歸檢查。
常見問題
IPA 檔案顯示的大小，會等於使用者從 App Store 下載的大小嗎？
不一定。IPA 是匯出或上傳產物，裝置變體可能交付不同內容。用 Xcode 報告與 App Store Connect 核對，不要以本地封裝檔推算所有裝置的下載量。
在 Xcode 27 裡，怎樣產生 App Thinning Size Report？
先對準備發布的構建執行 Archive，再在 Organizer 進入分發或匯出流程，依 Apple 文件產生報告。保留報告及相同匯出條件，才能與後續版本有效比較。
App Store Connect 哪裡能核對各裝置變體的大小？
開啟 App 對應的構建資訊，查看裝置相關大小資料。若資料尚未完整出現，先確認構建處理狀態，再與 Xcode 報告中的裝置變體比對。
App 超過蜂巢網路下載限制時，優先檢查哪些資料？
先核對 App Store Connect 的裝置變體大小與 Apple 文件所述限制，再檢查報告中的首次安裝資源和二進位檔。不要用 Archive 或 IPA 總大小判斷是否超限。
對需要反覆產生報告的小團隊來說，沿用個人電腦可能受硬碟空間、構建時段與環境一致性影響；購買一台專用 Mac 則會帶來硬體支出和閒置成本。若你只在提交前或版本驗收時需要 macOS，租用 VpsMesh 遠端 Mac 可讓你在不先購置本地設備的情況下完成 Archive、匯出與報告核對；可先查看遠端 Mac 租用方式與選項。若你需要長期持續運行、依賴實體介面，或必須完全掌控本地設備，購買自用 Mac 仍可能更合適。