很多 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 上架只需要一个签名 APKiOS 却要折腾证书、描述文件、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 Program99 美元/年适合个人开发者。公司开发者账号同样需要年费但要先在 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 --verbose4 /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 version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keymethod/key stringapp-store-connect/string keydestination/key stringexport/string keysigningStyle/key stringautomatic/string keystripSwiftSymbols/key true/ keyuploadBitcode/key false/ keycompileBitcode/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-idexample.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 提审只是一次例行的发布操作不需要再临时抱佛脚。如果你正被某个具体的提审问题卡住建议先按“证书 - 描述文件 - 构建号 - 上传工具 - 审核备注”的顺序排查。绝大多数问题都出在这五个环节里。