症状：新版本提交前，本地 IPA 比上一版大了一截，或者 App Store Connect 出现体积警告。
最快判断：本周先用 Xcode 27 导出 App Thinning Size Report，再到 App Store Connect 核对设备变体；Archive 和上传用 IPA 的文件大小，都不能直接当成用户下载大小。
准备提交新版本、发现应用体积增长的独立 iOS 开发者，先从测量口径开始。
维护多设备变体或多语言资源的开发者，可按报告找出真正需要精简的部分。
需要反复 Archive 和验收的小团队，则应把报告纳入每次发布的回归记录。
测量口径：报告和商店数据各回答什么问题
Archive、IPA、下载大小和安装占用不是同一个指标。Archive 是构建归档；IPA 是导出或上传的打包文件；下载大小是用户获取的压缩变体；安装大小则是应用落到设备后占用的空间。拿 Finder 显示的文件大小直接判断用户体验，很容易把不随应用分发的内容也算进去。
Apple 明确指出，APP、XCARCHIVE 和上传用 IPA 都不适合用来准确测量 App Store 用户获得的下载与安装大小。归档中可能包含供崩溃诊断使用的 dSYM 等文件，它们不属于用户设备上的应用本体。先看报告里的压缩、未压缩字段，再用商店数据复核，才是在比较同一种东西。Apple：测量应用大小与生成报告
在 Xcode 27 中，先 Archive，再从 Organizer 导出 Ad Hoc、Development 或 Enterprise 版本。导出时将 App Thinning 设为所有兼容设备变体，完成签名并导出到 Mac。随后在输出目录查找 App Thinning Size Report.txt。报告会列出通用包和不同变体的压缩、未压缩大小；前者用于估算下载体积，后者用于估算安装体积。Apple 也提供了使用 xcodebuild -exportArchive 自动导出报告的方式，适合纳入持续集成流程。
资源指标：先找真正随首装交付的文件
报告显示下载体积上升后，优先检查导出的变体，而不是盲目压缩项目里的所有图片。将 IPA 副本改为 ZIP 并解压，在应用包内检查资源目录、Assets.car、本地化内容、音频视频和随包数据。对照上一个版本，找新增的大文件、重复素材，以及已不再使用但仍被加入 Target 的资源。
Asset Catalog 可以按设备、分辨率、外观和语言组织资源，App Store 可据此为设备生成适用变体。但若同一素材被重复打包，或所有设备都要下载相同的大型内容，单纯启用目录不会自动解决资源管理问题。Apple：Asset Catalog 的资源变体机制
具体动作要对照使用场景：删掉确认未引用的素材；检查是否把文档、示例文件或旧语言资源意外加入应用；对大图、音视频评估更合适的格式和压缩方式。若内容并非首次启动所必需，再考虑按需提供或使用独立资源包。按需交付会增加网络请求、缓存和失败恢复等工程工作，不适合所有应用；先确认内容使用频率和离线需求，再决定是否拆分。Apple：基础体积优化建议；Apple：资源压缩与按需资源等进阶方法
03二进制指标：框架、编译设置与符号文件分开查
如果变体报告显示 App 本体而非资源占比明显上升，检查 Release 构建设置、嵌入式框架以及各 Target 的二进制变化。导出变体解压后，查看应用可执行文件和 Frameworks 目录；与上一版同一设备变体作差异比较。新加依赖、重复嵌入框架或发布配置改变，都值得优先核实，但不要仅凭文件名推断它就是增长原因。
检查目标和项目的最终生效设置，确认 Release 优化配置没有被某个 Target 或配置文件覆盖。Apple 的构建设置文档将优化级别区分为面向速度和面向体积的选项；修改前应先记录当前值，并以相同构建方式重新导出报告，避免把性能、调试或兼容性变化误当成免费的体积收益。Apple：构建设置中的优化级别；Apple：查看构建设置的最终生效值
04⚠️ dSYM 是符号化崩溃日志用的诊断文件。不要把整个 Archive 的体积或诊断符号文件的体积加进 App 下载大小；需要判断用户拿到什么，应回到设备变体报告和 App Store Connect。
设备变体指标：不要只凭一个 IPA 推断所有机型
App Thinning 会根据设备和系统版本生成变体。不同变体可能包含不同的资源与二进制组合，因此通用包不一定代表某一款 iPhone 的实际下载结果。检查多设备、多语言应用时，逐项核对你支持的设备类型；若资源目录有设备专用素材，也要确认它是否确实被正确标注。
报告负责在发布前估算，App Store Connect 则提供上传处理后的变体大小信息。进入应用的 TestFlight 页面，打开对应构建的详情，再查看 Build Metadata 中的 App File Sizes。这里可以对照压缩文件大小、核心内容大小、额外应用内内容等数据，并查看设备变体的下载和安装大小。获准发布后，App Store 还会处理二进制，最终商店文件大小不一定与上传文件完全相同。Apple：在 App Store Connect 查看构建大小与变体
05下载体验指标：蜂窝网络提示不等于安装占用警告
对照 App Store Connect 的变体下载大小和警告，判断是否需要立刻优化。Apple 文档说明，设备变体超过 200 MB 时，构建列表和 App File Sizes 中会出现蜂窝网络下载限制警告；不要把这个门槛套到未压缩安装大小上，也不要把提示扩展为所有用户、所有网络条件下都无法下载。
还要把下载和安装两类影响分开判断。下载较大，用户首次获取时需要传输更多数据；安装占用较大，则可能挤压设备可用空间。若增长集中在首次安装并非必需的媒体或语言包，评估延后交付；若主要来自必要功能代码或关键资源，则应衡量压缩、删减与功能取舍，不能为了数字牺牲核心体验。
按条件选下一步：
- 若报告与 App Store Connect 都显示某个目标变体增长，先拆解该变体内的资源和框架；否则不要仅凭 IPA 变大就重做资源。
- 若增长来自重复、未使用或不应首装交付的素材，先清理或评估按需提供；否则保留首装内容，避免增加不必要的下载依赖。
- 若下载变体触发蜂窝网络警告且目标用户常在移动网络安装，优先检查首次下载必须包含的内容；若主要问题是安装占用，则围绕设备存储和内容使用场景做决策。
- 若不同变体结果差异明显，逐机型复核资源切片；若变体表现接近，再回查全局二进制或公共资源。
| 复核对象 | 数据入口 | 适合做的判断 |
|---|---|---|
| 上传文件 | 本地导出的 IPA | 检查导出物，不直接代表用户下载大小 |
| 预估变体 | App Thinning Size Report.txt |
比较变体的压缩下载与未压缩安装大小 |
| 已上传构建 | App Store Connect 的 Build Metadata | 按设备复核 App File Sizes 与警告 |
| 构建归档 | Archive 及其中的诊断文件 | 不把整个归档当成商店交付体积 |
Apple 还列有应用包与可执行文件的上传大小上限，但这类构建限制与蜂窝网络下载提示不是同一件事。只有遇到上传或处理失败时，才需要对照相应平台的构建上限；单纯出现用户下载体积增长，应继续按设备变体报告定位。Apple：各平台构建文件大小上限
06回归检查：让每次构建都能公平比较
体积回归不是比较两个随手导出的文件。固定 Git 提交、Xcode 版本、Scheme、Release 配置、导出方式和 App Thinning 选项；每次保存报告，并记录通用包及目标设备变体的压缩、未压缩数据。若导出选项或支持设备范围改变，应在记录中注明，否则新旧报告口径不同，差异无法说明是代码变化还是构建方式变化。
重复 Archive 和导出需要 macOS 环境。若你暂时不想为偶发发布任务购置本地设备，可以先比较自购 Mac 与远程 Mac 的使用方式：远程环境便于按需运行 macOS 工具链，但仍需评估网络访问、文件传输和密钥管理。租用方式和套餐选择可参考VpsMesh 的 Mac 租赁说明。如果你需要长期、稳定的高频构建，或必须连接本地物理设备，先核算自有 Mac 的持续使用成本与设备需求；远程租赁并非所有工作流的最佳方案。
07常见问题
详细问答见文章配套 FAQ；发布前记住三条：上传 IPA 不等于用户下载包；Xcode 报告用于预估和定位；App Store Connect 的设备变体数据用于发布复核。
如果你的现有方案是只看本地 IPA、手工把体积记在表格里，或等提交后才检查，容易漏掉变体差异、符号文件误算和回归发生版本。对需要临时反复 Archive、导出并核对报告的团队，远程 Mac 可免去专门购置一台本地 Mac 的前置投入；但长期高频构建或依赖实体接口时，应优先比较自购设备是否更合适。需要 macOS 环境完成下一轮体积验收时，可查看 VpsMesh 的远程 Mac 方案，再按实际使用周期和交付方式决定。