Xcode Organizer 显示 “Upload successful” 带绿勾。Transporter 状态条到 100%，写着 “Delivered”。你刷 App Store Connect → TestFlight → Builds，build 不见。半小时过去——还是没有。你重 archive、重传，结果一样。上传用的 Apple ID 邮箱一片寂静。你开始怀疑上传到底成没成，或者某个你看不见的校验步骤悄悄把它拒了。
最快的修法（先做这一步）：完整等满 30 分钟，硬刷新 TestFlight Builds 页，然后查上传那个 Apple ID 的邮箱（含垃圾箱），看有没有标题是 “Your app build is invalid” 的邮件，或正文里任何 ITMS-9xxxx 码。截至 2026 年 6 月，最常见的静默拒回是隐私 manifest 缺失或无效（ITMS-91053 / ITMS-91056），它会在 build 进入 UI 之前就把它干掉，但一定会发邮件。在排除掉邮件之前不要重传——同一个 build 号重传只会占掉一个号位，什么都不改变。
多数情况下 build 在三种静默状态之一：
- 还在上传后的 Processing 阶段（Apple 处理完它就会出现），
- 在 validation 阶段被静默拒回，拒信邮件已发出但你还没看到，或者
- 路由到了错的 App 记录或 Team，正躺在你没去看的地方。
每种状态对应不同修法，跑错的修法（多半是重传）只会增加摩擦。
先判断你属于哪一类
| 现象 | 最可能的原因 | 跳到 |
|---|---|---|
| build 出现了，状态是 Processing | 正常流水延迟 | 原因 1 |
| build 完全不见 + 收到了 Apple 邮件 | validation 拒回 | 原因 2 |
| build 完全不见、没邮件、有多个 team / App ID | 传错了 App / Team | 原因 3 |
| 上传”成功”但版本号 / build 号已存在 | build 号撞了 | 原因 4 |
| 账号显示 agreement / 税务 / 银行警告 | 账号被挂起 | 原因 5 |
| 在不稳的网络或公司代理下上传 | 传输不完整 | 原因 6 |
常见原因
按命中率排序。
1. Apple 还在 Processing
上传后 Apple 流水会做资源提取、validation、dSYM / 符号处理。这一步完成前 build 不会出现在 TestFlight 或 App Store build picker 里，完成时 Apple 会给上传的 Apple ID 发邮件。典型等待 10-60 分钟。高峰窗口（WWDC 刚结束、新 iOS 正式版发布、Xcode 大版本发布），2-6 小时也正常。
注意 bitcode 已经没了：Xcode 14 移除了它，App Store 不再接受 bitcode 提交、也不再在后端重新编译二进制，所以过去那种”等 bitcode 重编译”的延迟不存在了。Processing 比以前快，正因为如此，一个已经”消失”好几个小时的 build，更可能是被拒了，而不是排队慢。
如何判断：App Store Connect → TestFlight → Builds。有时能看到 build 已列出，状态是 Processing，而不是完全消失。如果真的完全消失，先等 30 分钟刷新再下结论。
2. 在 validation 阶段被静默拒回
上传后 Apple 对二进制做静态分析。失败（Info.plist 缺 key、不支持的架构、禁用 API、entitlement 和 App ID 不匹配、隐私 manifest 缺失）会发一封标题类似 “App Store Connect: Your app build is invalid” 的邮件，但 build 本身从不出现在 App Store Connect UI。邮件可能 5-30 分钟才到。
截至 2026 年 6 月，这一类里最主流的拒回是隐私 manifest要求：自 2024 年 5 月 1 日起，只要 build 调用了必须说明理由的 API（required-reason API）（如 NSPrivacyAccessedAPICategoryUserDefaults、FileTimestamp、SystemBootTime、DiskSpace 这些类别），却没在 PrivacyInfo.xcprivacy 文件里声明理由，Apple 就会拒。很多时候这来自你管不到的第三方 SDK，而不是你自己的代码。
如何判断：查上传 Apple ID 邮箱（含垃圾箱）有没有 “invalid” 邮件。常见码：
| 码 | 含义 |
|---|---|
ITMS-91053 | 缺 API 声明（required-reason API 没在隐私 manifest 里声明） |
ITMS-91056 | 隐私 manifest 无效 |
ITMS-90161 | entitlement 缺失 / 无效 |
ITMS-90201 | binary 无效 |
ITMS-90685 | CFBundleIdentifier 撞了（App 内部存在重复 bundle ID） |
拒回的唯一出路是：修掉邮件里点名的问题、递增 CFBundleVersion、重 archive、重传。被拒的那个 build 号已经废掉了。
3. 传到了错的 App 记录或 Team
你有两个 App ID（生产 + dev），Xcode 因为 scheme 或签名配置挑了 dev 那个。或者你的 Apple ID 同时在两个 team，上传去了副 team。Build 在 App Store Connect 里，只是不在你看的那个地方。
如何判断：在 App Store Connect 打开 team / 账号切换器（当前 UI 在右上角账号菜单里），切到你所属的每个 team。每个 team 都看一遍 Apps 和 Activity → All Builds。再把 archive 里的 Bundle ID 和你以为传到的那个 App 在 App Store Connect 里期望的对一遍。
4. Build 号和已有 build 撞了
同一个 CFBundleShortVersionString 下，每个 CFBundleVersion 必须唯一。如果你传 1.2.3 (42)，而之前已经存在过 1.2.3 (42)（哪怕被丢弃了），Apple 可能接受了传输，却静默丢掉重复的那个，不给任何 UI 反馈。
如何判断：Activity → All Builds 里查 1.2.3 下有没有任何 (42)。修法很简单：每次上传前永远递增 build 号。
5. Agreements / 银行 / 税务卡住了处理
只要 Paid Apps 协议过期、税务信息过期、或银行信息无效，整个账号都会被挂起。上传可以在传输层成功，而 Apple 静默把 build 停在那里。
如何判断：App Store Connect → Business → Agreements, Tax, and Banking。任何不是 Active 的状态都可能卡住处理。
6. Transporter / Xcode 报”成功”但传输不完整
上传途中网络抖动，或公司代理把头剥掉，会让客户端报成功，而 Apple 其实没收到能用的东西。二进制发出去了，但从没被注册。
如何判断：改用 Transporter（Mac App Store 上免费）重传，它的错误信息比 Xcode Organizer 透明得多，注意 “Delivered” 后面任何警告行。
需要收集的信息
- 精确上传时间戳 + 用的工具（Xcode Organizer / Transporter /
xcrun altool/ App Store Connect API）。 - 上传用的 Apple ID 以及它属于哪些 team。
- archive 的 Bundle ID、版本（
CFBundleShortVersionString）、build 号（CFBundleVersion）。 - 上传后任何提到你 App 的 Apple 邮件，包括
ITMS-码。 - App Store Connect → Activity → All Builds 里该 App 的日志。
最短修复路径
Step 1：等 30 分钟再硬刷新
App Store Connect UI 不会稳定地自动刷新。30 分钟后硬刷新（Safari/Chrome 按 Cmd+Shift+R）TestFlight → Builds 页，也刷一下 Activity → All Builds。
Step 2：查上传者邮箱
搜上传用 Apple ID 的邮箱，覆盖过去 24 小时，找：
- 标题含 “Your app build is invalid” 或 “App Store Connect”。
- 正文里的
ITMS-9xxxx码（见上面的表）。 - 具体问题，如 “missing UIApplicationSceneManifest” 或某个点名的隐私 manifest 类别。
垃圾箱拦截这类邮件比你想的更频繁。如果存在这样一封邮件，那你遇到的是拒回（原因 2），不是排队慢——重传同一个 build 没用。
Step 3：核对 Bundle ID、版本、build 号
打开 archive 的 Info.plist（Xcode → Organizer → 右键 archive → Show Package Contents → Products/Applications/MyApp.app/Info.plist），或命令行读：
plutil -p MyApp.xcarchive/Products/Applications/MyApp.app/Info.plist \
| grep -E "BundleIdentifier|BundleVersion|BundleShortVersionString"和 App Store Connect → App Information → Bundle ID 对照。任何不一致（拼写错、.dev 后缀有无）都意味着 build 去了别的 App 记录。
Step 4：核对 team 和 App
打开账号 / team 切换器（当前 App Store Connect UI 在右上角），把你 Apple ID 归属的每个 team 都过一遍。每个 team 都看 Apps 和 Activity → All Builds。Build 可能落在了另一个 team 下的平行项目里。
Step 5：递增 build 号，用 Transporter 重传
如果 build 真的丢了，且你已等满 60 分钟还没收到邮件：
- Xcode 里递增
CFBundleVersion（如42→43）。 - 重 archive。
- 打开 Transporter，把新的
.ipa拖进去，点 Deliver。Transporter 报 validation 错误比 Xcode Organizer 清楚。
或用命令行。截至 2026 年 6 月，xcrun altool 在 App Store 上传场景仍然受支持（注意：altool 只是在 notarization（公证）场景被弃用、由 notarytool 替代，App Store 投递并没有被弃用）：
# 先 validate，别在已知有问题的二进制上白白烧掉一个 build 号
xcrun altool --validate-app -f MyApp.ipa -t ios \
--apiKey "$ASC_KEY_ID" --apiIssuer "$ASC_ISSUER_ID"
xcrun altool --upload-app -f MyApp.ipa -t ios \
--apiKey "$ASC_KEY_ID" --apiIssuer "$ASC_ISSUER_ID"--validate-app 会跑 Apple 的静态检查，在上传占掉 build 号之前就把同样的 ITMS- 错误暴露出来。（用 app-specific password 的 -u/-p 认证仍然能用，但 App Store Connect API key 更长期可靠。）
Step 6：在 App Store Connect 确认
上传后等 10-30 分钟，看 App Store Connect → TestFlight → Builds。新 build 应该先显示 Processing，然后切到 Ready to Submit（或 Missing Compliance，这只是需要补一个出口合规的回答）。
怎么确认已经修好
- 新 build 出现在 App Store Connect → TestFlight → Builds 里，版本和 build 号都对得上。
- 状态在一小时内从 Processing 切到 Ready to Submit。
- 上传用的 Apple ID 收到 Apple 的”processing 完成”邮件。
- 在 App Store → Build picker 里能选到这个 build 去提交。
如果还是没修好
- 下次真实上传前，先在本地跑
xcrun altool --validate-app，让 validation 错误本地暴露。 - 查 Apple System Status 页面，看有没有 TestFlight / App Store Connect 故障；故障期间上传会被停车。
- 手动检查 IPA 里缺哪些 entitlement：
unzip MyApp.ipa -d Inspect/
codesign -d --entitlements - "Inspect/Payload/MyApp.app"- 排查隐私 manifest 拒回是不是某个第三方 SDK 引起的。Apple 在 Describing use of required reason API 里记录了 required-reason API 规则。
- 兜底向 App Store Connect support 报工单，附上上传时间戳、用的 Apple ID 和 Bundle ID，他们能确认上传到底有没有到位。
常见问题
多久之后才能判定 build 真的丢了？ 正常流量下 60 分钟。bitcode 移除后流水更快了，所以超过一小时还不见，更可能是被拒（去查邮件）而不是排队慢。WWDC 那周或新 iOS 正式版当口，留 2-6 小时。
上传显示 “Delivered” 但我一封邮件都没收到，怎么办？ “Delivered” 只代表字节到了 Apple，不代表 build 被接受。一小时后还没邮件，通常是原因 3（传错 team / App）或原因 6（传输不完整）。切到每个 team、各看一遍 Activity → All Builds；如果还是什么都没有，用 Transporter 重传并盯着它的日志。
我收到 ITMS-91053，可我没改过隐私相关代码，为什么？
required-reason API 强制检查（2024 年 5 月 1 日起）会扫描你的整个二进制，包括第三方 SDK。升级某个依赖就可能引入对 required-reason API 的调用。把那个 SDK 升到自带 PrivacyInfo.xcprivacy 的版本，或自己补上声明，然后递增 CFBundleVersion 重传。
被拒的那次上传后，我能复用同一个 build 号吗？
不能。一个 build 号一旦被占用（哪怕是被拒的上传占的），在那个版本号下 Apple 就不会再接受它了。永远递增 CFBundleVersion。
我还需要从 App Store Connect 下载 dSYM 吗？ 不用了。Xcode 14 移除 bitcode 后，Apple 不再重新编译你的二进制，所以你本地 archive 里的 dSYM 就是最终版。直接从 archive 取，不用去 App Store Connect 下。
预防建议
- 每次上传前永远递增 build 号；CI 配置自动递增
CFBundleVersion。 - 在 CI 加一个预上传步骤
xcrun altool --validate-app，让问题（包括隐私 manifest 缺口）在二进制到 Apple 之前就大声报错。 - 在引入或升级第三方 SDK 之前，先审一遍它有没有覆盖
PrivacyInfo.xcprivacy。 - 保持 Agreements / Banking / Tax 状态为绿；每月检查一次。
- 生产上传都用 Transporter；它的错误报告比 Xcode Organizer 清晰。
- 订阅该账号的 Apple Developer 邮件通知，第一时间看到 processing 拒回。