很多 iOS 开发者都经历过这样的场景：Xcode 里运行得好好的 App，一旦打包提交到 App Store，就开始被各种理由拒绝，从“2.1 大礼包”到“5.1.1 隐私权限”，从“截图尺寸不对”到“无法登录测试账号”。更让人头疼的是，证书突然失效、描述文件过期、上传工具报错，这些问题经常在周五下午集中爆发。
如果你把 iOS App 提交只看作“点一下 Upload 按钮”，那它确实像开盲盒。但实际上，App Store 提交是一个从证书管理、打包构建、隐私配置到审核材料准备都能标准化执行的工程流程。真正成熟的团队，不是每次提审都赌运气，而是把整套流程沉淀成清单和脚本，让每次提交都稳定、可复现、可回溯。
这篇文章会围绕 “Ask HN: How do you handle iOS app submissions?” 这个问题，拆解 iOS App 提审的完整链路：包括提交前要准备什么、证书和描述文件怎么管理、如何用 Xcode 和命令行工具打包上传、TestFlight 内测怎么用、被拒后如何排查、以及团队协作时如何通过自动化工具减少人为失误。不管你是独立开发者，还是团队里的 iOS 负责人，照着这篇文章梳理一遍，都能把提审从“玄学”变成“流程”。
1. 为什么 iOS App 提交比 Android 更复杂
很多刚接触 iOS 开发的同事会困惑：为什么 Android 上架只需要一个签名 APK，iOS 却要折腾证书、描述文件、Bundle ID、权限声明、隐私清单一大堆东西？
这里的核心差异在于系统封闭性和分发渠道的唯一性。Android 应用可以通过商店、官网、第三方市场等多种方式分发，签名主要用于校验 APK 完整性；而 iOS 应用正常情况下只能通过 App Store 和 TestFlight 分发，苹果需要在安装前确认三件事：这个 App 是谁开发的、有没有经过开发者账号授权、是否包含系统的能力权限（如推送、支付）。
所以苹果设计了一套基于证书和描述文件的签名体系：
- 证书用来证明开发者身份，有点像你的身份证。
- 描述文件用来声明这个 App 能安装到哪些设备、能使用哪些能力，有点像工作证上的权限范围。
- App ID 用来唯一标识你的应用，对应 Xcode 里的 Bundle Identifier。
这三者一旦对不上，上传就可能被拒，或者干脆报错。
另外，苹果审核不只是检查代码能不能跑，还会看应用的功能是否符合《App Store 审核指南》，包括隐私政策、用户生成内容、购买规则、设计规范等。近几年的趋势是隐私合规要求越来越严格，很多 App 被拒不是因为技术问题，而是因为没有写清楚隐私标签、没有提供账号注销入口、或者在启动时强制要求定位权限。
所以，处理 iOS App 提交的第一原则是：把提审当成一次软件发布工程，而不是一次点击操作。只有在提交前把物料、签名、配置、审核材料都准备好，后续流程才会顺利。
2. 提交 iOS App 前必须准备好的完整物料清单
在打开 Xcode 打包之前，先对照下面这份清单逐项检查。缺少任何一项，后续都可能被打回。
2.1 开发者账号与角色权限
- 个人开发者账号（Apple Developer Program）：99 美元/年，适合个人开发者。
- 公司开发者账号：同样需要年费，但要先在 Apple Developer 后台验证公司主体信息，适用于企业发布。
- 如果是团队协作，需要在 App Store Connect 中给成员分配角色，比如 Admin、App Manager、Developer 等。不要所有人都拿最高权限，推荐按最小权限原则分配。
2.2 App ID、证书与描述文件
这是最容易出错的部分。需要确认：
- Bundle Identifier 和已注册的 App ID 完全一致。
- 发布证书（Distribution Certificate）没有过期，且私钥还在。
- 描述文件（Provisioning Profile）包含正确的 App ID 和证书，有效期正常。
- 如果 App 使用推送、iCloud、Apple Pay 等能力，描述文件对应的 Capability 必须已经开通。
2.3 隐私与数据声明
- App 隐私标签（App Privacy）需要在 App Store Connect 后台填写，说明收集了哪些数据类型。
- 如果 App 需要访问相机、相册、定位、通讯录、麦克风等，必须在 Info.plist 中提供用途描述字符串，比如 NSCameraUsageDescription。
- 如果涉及用户生成内容，建议准备举报、屏蔽和内容过滤机制，否则可能触发审核指南 1.2。
2.4 上架素材
- App 图标：不能有透明通道，尺寸需符合各型号设备要求。
- 截图：6.7 英寸、6.5 英寸、5.5 英寸等尺寸的截图，具体要求以 App Store Connect 后台为准。
- 审核备注：如果包含登录功能，尽量提供测试账号；如果包含特殊功能，说明使用路径。
- 隐私政策 URL：即使 App 不收集用户数据，也建议准备一个公开可访问的隐私政策页面。
2.5 版本与构建号规范
建议提前约定版本号和构建号规则，避免多次提交时出现混乱。常见做法是：
- CFBundleShortVersionString（版本号）：1.0.0，每次功能更新递增，遵循语义化版本。
- CFBundleVersion（构建号）：1 或 1001，每次上传到 App Store Connect 都递增，TestFlight 和 App Store 都依赖它区分不同构建。
如果多次上传同一构建号，App Store Connect 会报“构建号已存在”的错误。
3. 证书、描述文件与签名机制详解
3.1 证书体系的通俗理解
可以把证书和描述文件的关系理解为：
- 开发者证书：相当于印章，证明 App 是你开发的，没有被篡改过。
- 描述文件：相当于许可证，证明这台设备或这个分发渠道允许运行这个 App。
开发证书用于开发调试，发布证书用于上传 App Store 或 Ad Hoc 分发。很多人提交失败，就是因为开发环境用的证书正常，但打包发布时选错了证书类型，或者发布证书已经过期。
3.2 证书与描述文件的常见操作
在 Mac 上，可以通过钥匙串访问（Keychain Access）查看证书。命令行检查更直接：
# 查看本机已安装的开发者证书 security find-identity -v -p codesigning # 查看描述文件信息（profile 文件路径自行替换） security cms -D -i /path/to/YourProfile.mobileprovision如果输出里只看到开发证书，看不到 Apple Distribution 证书，说明发布证书没有安装到本机。这种情况在团队协作中尤其常见：某台 Mac 上传过 App，另一台新 Mac 拿不到私钥，就无法用同一个证书重新签名。
3.3 导出证书和私钥
当团队里只有一台机器有发布证书私钥时，必须把证书和私钥导出，在多台构建机之间安全传递：
- 打开“钥匙串访问”。
- 在“登录”钥匙串里找到 Apple Distribution 证书，展开后选中对应的私钥。
- 右键导出为
.p12文件，设置强密码。 - 将
.p12文件上传到团队的密钥管理工具，或通过安全渠道分发给多台 Mac。
导出后的.p12文件不要放到公开仓库，也不要通过聊天工具明文传输。私钥泄露意味着任何拿到它的人都可以冒充你的团队签名 App。
3.4 签名验证与常见错误
用codesign命令可以验证签名：
codesign -dv --verbose=4 /path/to/YourApp.app如果看到类似 “code object is not signed at all” 的提示，说明签名缺失。如果提示证书不受信任，检查证书链是否完整。
这个环节最常见的坑是：更新了证书但描述文件没有重新生成，或者反过来。任何一次证书变更，都要同步生成并下载新的描述文件。
4. Xcode 打包上传与命令行自动化
4.1 用 Xcode 完成 Archive 导出
在 Xcode 中，选择目标设备为 “Any iOS Device (arm64)”，然后执行 Product -> Archive。Archive 成功后，Xcode Organizer 会列出当前构建。这时可以选择：
- Distribute App -> App Store Connect -> Upload。
- 向导会要求选择签名方式和上传工具。
使用 Xcode 向导的优点是图形化、直观，适合个人开发者。但缺点是每次手工操作，重复步骤多，也不利于团队协作。
4.2 使用 xcodebuild 和 altool 自动化打包
在 CI 或运维场景中，更推荐用命令行完成 Archive 和导出。这是团队自动化提审的核心方式。
第一步：Archive。
xcodebuild archive \ -workspace YourApp.xcworkspace \ -scheme YourAppScheme \ -configuration Release \ -archivePath ./build/YourApp.xcarchive \ -allowProvisioningUpdates第二步：导出 IPA。需要准备一个ExportOptions.plist，声明导出方式和签名信息。示例配置如下：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>method</key> <string>app-store-connect</string> <key>destination</key> <string>export</string> <key>signingStyle</key> <string>automatic</string> <key>stripSwiftSymbols</key> <true/> <key>uploadBitcode</key> <false/> <key>compileBitcode</key> <false/> </dict> </plist>然后执行导出：
xcodebuild -exportArchive \ -archivePath ./build/YourApp.xcarchive \ -exportPath ./build/export \ -exportOptionsPlist ./build/ExportOptions.plist \ -allowProvisioningUpdates第三步：上传 IPA 到 App Store Connect。新版本 Xcode 推荐使用xcrun altool，也可以通过 Transporter 上传。altool 的用法如下：
xcrun altool --upload-app \ -f ./build/export/YourApp.ipa \ -t ios \ -u your-apple-id@example.com \ -p your-app-specific-password注意：这里的密码不是 Apple ID 登录密码，而是在 Apple ID 后台生成的 App 专用密码。为了更高的安全性，也可以使用 App Store Connect API Key 配合altool或第三方工具进行认证。
4.3 Transporter 的适用场景
Transporter 是苹果提供的上传工具，支持从 App Store Connect 后台下载。它的优势是稳定、会自动检测 IPA 文件的常见问题，适合在本地手动上传时使用。但要注意，Transporter 有时会因为网络或 TLS 问题失败，需要按第 7 章排查。
5. TestFlight：正式提审前的安全网
TestFlight 是苹果官方的内部测试分发平台。所有要提审的构建，都建议先在 TestFlight 上跑一轮，因为它的审核策略比 App Store 宽松很多，适合内部验证功能和稳定性。
5.1 内部测试与外部测试
- 内部测试：最多可添加 100 名成员，无需审核，构建上传后几分钟即可安装。
- 外部测试：最多可添加 10000 名测试员，需要进行 Beta 审核，审核时间通常比正式提审短。
内部测试适合开发人员、产品经理、测试人员快速验证。外部测试适合需要更大范围真机反馈的产品。
5.2 TestFlight 提审前的自检
即使有 TestFlight，也不能跳过正式提审的准备。建议在 TestFlight 版本上重点检查：
- 冷启动是否崩溃。
- 登录和支付流程是否完整。
- 弱网环境下的表现。
- 权限弹窗出现时机是否合理。
- 是否有敏感信息打印在控制台或日志中。
如果 TestFlight 版本就有明显问题，不要急着提交 App Store 审核。苹果审核团队会先安装最新构建进行测试，崩溃率过高基本直接打回。
5.3 把 TestFlight 作为提审流程的一部分
建议这样组织流程：开发完成后先打一个 TestFlight 内部版，QA 和产品验收；验收通过后再用同一个构建号走向 App Store 审核。这样可以保证提审的构建和测试的构建是同一份代码，避免“测试的没问题，提审的代码不一致”这种人为失误。
6. App Store 审核被拒的常见原因与排查思路
苹果审核被拒是常态，关键是快速定位原因、给出说明、重新提交。下面这张表覆盖了最常见的几类拒绝原因。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 2.1 大礼包：信息不完整 | 缺少审核材料，或功能入口不明确 | 阅读拒绝邮件里的具体说明 | 补充审核备注、演示视频、测试账号，明确说明核心功能 |
| 4.2/4.3 设计或功能最低要求 | App 功能单一，或只是 H5 壳 | 对照审核指南逐条检查 | 增加原生功能或明确产品差异；如果不认可可申诉 |
| 5.1.1 隐私权限被拒 | 权限弹窗出现在非必要时机，或用途说明含糊 | 查看 Info.plist 中的描述字符串 | 修改用途说明，延迟弹窗，在用户真正需要用该功能时才请求权限 |
| 2.5.1 使用了私有 API | 代码中调用了非公开 API | 用nm或符号检查工具查看二进制符号 | 移除相关调用，改用系统公开 API |
| 崩溃或性能问题 | 启动崩溃、闪退、卡顿 | 查看 TestFlight 崩溃日志，解析 dSYM | 修复崩溃后重新提交 |
| 无法登录 | 审核团队无法用测试账号登录 | 确保账号有效，且填写在审核备注中 | 定期检查测试账号，或提供视频演示登录流程 |
6.1 关于“2.1 大礼包”
苹果的 2.1 是综合性条款，很多开发者收到 2.1 被拒时一头雾水。其实它多数时候不是在否定你的产品，而是因为审核人员看不懂你的 App 是做什么的，或者无法复现页面流程。处理方式是提供清晰的材料：
- 在审核备注里写明 App 的使用场景。
- 如果需要登录，给出测试账号和密码。
- 如果功能必须有特定环境，提供演示视频。
6.2 加急审核什么时候用
如果 App 遇到严重 Bug、必须立刻修复上线，或者涉及时间敏感的事件（比如赛事直播、金融交易），可以通过 App Store Connect 的“申请加急审核”入口提交请求。注意，加急审核不是普通催促通道，滥用会影响团队在苹果侧的可信度。只有在问题足够严重、时间明确紧张时才建议使用。
7. 常见报错与工具链问题排查
提审过程中，除了审核被拒，还有大量工具链层面的报错。这些报错经常在最后上传阶段出现，非常消耗时间。下面是几个高频问题。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 上传报错：证书不受信任 | 证书链不完整，或系统日期错误 | 检查钥匙串中证书是否显示为绿色 | 下载并安装 Apple WWDR 证书 |
| 描述文件不包含新 App ID | 描述文件和 App ID 不匹配 | 在开发者后台确认描述文件的 App ID | 重新生成并下载描述文件 |
| Transporter 报错 -1200 或 TLS 相关错误 | 网络环境异常、防火墙拦截、证书校验失败 | 检查系统网络代理、TLS 设置 | 关闭不必要的代理，更新系统证书，重试上传 |
| 跨平台工具构建后报 uni-push 未配置 | manifest 中声明了 Push 能力，却没有对应 iOS 推送证书 | 检查跨平台配置文件中的 Push 开关 | 在开发者后台配置 Push 证书，并确保 Profile 包含 Push 能力 |
| 提示 Bundle ID 已存在 | 另一个 App 已占用该 Bundle ID | 在 App Store Connect 中查看所有 App | 更换 Bundle ID，或在现有 App 记录下继续提交 |
| TestFlight 构建不可用 | 构建还没处理完成，或缺少出口合规信息 | 等待一段时间后刷新页面 | 每次上传后定期刷新，直到状态变成“可供测试” |
7.1 TLS 相关错误的处理
NSURLErrorDomain -1200 是上传、下载、WebView 场景里常见的 TLS 错误。它通常不是你的代码写错了，而是网络层面阻止了 HTTPS 连接。排查顺序建议如下：
- 检查 Mac 的系统日期和时间是否正确。
- 检查是否需要更新系统证书（执行
sudo update-ca-certificates等适合 Linux 的命令在 Mac 上是不同的，Mac 会自动更新系统根证书，但企业网络可能插入自定义 CA）。 - 检查当前网络是否开启了 HTTPS 代理，代理证书是否受信任。
- 换一个网络环境重试。
7.2 跨平台打包场景
使用 uni-app、Flutter、React Native 等跨平台框架时，网上很多报错来自原生配置没完成。比如 uni-app 的uni-push报错，核心原因通常是：在 manifest 里勾选了 Push 能力，但 iOS 推送证书没有在开发者后台配置，或描述文件没有重新生成。
遇到这类报错，不用去改复杂业务代码，而是回到证书配置链路：检查推送证书是否有效、描述文件是否包含推送服务、Bundle ID 是否一致。工具链报错的排查顺序，永远是“先检查配置，再检查代码”。
7.3 关于抓包工具的使用边界
很多同学习惯用 Charles 或类似工具调试接口，这在本地开发环境很方便。但要注意，不要对 App Store 上传通道或生产环境随机抓包，这既可能触发安全告警，也不符合隐私合规要求。抓包调试只建议在开发阶段的本地环境进行，并且在测试结束后移除相关信任证书。
8. 团队协作与自动化工程实践
当 iOS 提审不再是一个人完成的任务，而是开发、测试、产品、运维共同推动的流程时，工程化的价值就会显现出来。
8.1 用 App Store Connect API 替换账号密码
在 CI 中自动上传 IPA 时，不要在脚本里明文写 Apple ID 和 App 专用密码。更规范的做法是使用 App Store Connect API Key。创建方式：
- 登录 App Store Connect，访问“用户和访问”->“密钥”页面。
- 生成一个具有 App 管理权限的 API Key。
- 将密钥文件保存到安全的密钥管理服务，不要提交进 Git。
密钥文件是.p8格式，配合fastlane或altool使用。使用 API Key 可以精确控制权限、随时撤销，比共享密码更安全。
8.2 证书和描述文件的共享方案
团队超过两个人时，证书和描述文件很容易乱。推荐两种方案：
- 方案一：把
.p12和.mobileprovision文件统一放在密钥管理工具或加密存储中，命名规范为项目名-环境-证书类型。 - 方案二：使用 fastlane match。它会用 Git 仓库保存加密后的证书和描述文件，团队成员执行
fastlane match appstore即可自动安装正确版本。
fastlane match 的运行逻辑是：证书和描述文件以加密方式存储在 Git 仓库，首次执行时通过密码解密，安装到本机钥匙串。这样即使新成员加入，也能在两分钟内拿到全套签名资源。
8.3 可复现的存档与回滚
每次提审前，建议记录以下信息：
- Git commit 号或代码分支。
- Xcode 版本。
- 使用的证书和描述文件名称。
- 构建号。
- 上一版可用的构建号。
这样如果审核被拒或线上出问题，可以快速回滚到上一个可用的构建，而不是靠记忆找版本。回滚方式是在 App Store Connect 中选择之前通过的构建重新发布。
8.4 安全边界与最小权限
在团队中要严格控制证书和账号权限：
- 发布证书私钥只给需要打包发布的成员。
- App Store Connect 账号按角色分配，不要所有人都是 Admin。
- API Key 定期轮换，离职成员立即撤销权限。
- 不在日志中打印 Apple ID 或密钥。
8.5 自动化提审的最小闭环
不管是否使用 fastlane，都应该把提审做成一个可重复执行的最小闭环：
# 1. 更新版本号和构建号 # 2. Archive # 3. 导出 IPA # 4. 上传 TestFlight # 5. 等 TestFlight 构建可用 # 6. 发起 App Store 审核用脚本把这六步串起来，每步增加日志和产物路径。这样每次提审都有迹可查，不会出现“项目没问题但提审构建不对”的情况。
9. 收尾：把提交从“玄学”变成“流程”
处理 iOS App 提交的核心不是祈祷审核顺利，而是让每一次提审都基于同一个可重复的流程。证书提前检查、描述文件按项目隔离、Archive 流程固化、TestFlight 先测一轮、审核材料提前写好，能做到这五步，绝大多数被拒原因和工具链报错在提交前就已经被过滤掉了。
真正值得投入时间的，不是每周去猜苹果会不会打回，而是把提审清单写进团队文档，把证书和配置收敛到自动化管理工具里。等到一套流程稳定以后你会发现，iOS 提审只是一次例行的发布操作，不需要再临时抱佛脚。
如果你正被某个具体的提审问题卡住，建议先按“证书 -> 描述文件 -> 构建号 -> 上传工具 -> 审核备注”的顺序排查。绝大多数问题都出在这五个环节里。
