Hacker News 上隔一段时间就会有人发帖问你们团队到底怎么处理 iOS App 的提交和审核提问的人往往不是刚上手而是已经踩过一圈坑——证书时不时失效、描述文件对不上、xcodebuild 导出的包传到一半失败、提交审核后又因为元数据问题被拒。这个问题的答案并不复杂但确实是一条多环节链路签名配置、归档导出、Transporter/altool 上传、TestFlight 内测、App Store Connect 元数据填写、审核备注最后才是点击提交审核。这篇文章把这条链路完整过一遍重点放在“可执行”三个字上。你不需要再去搜几十篇零零碎碎的教程只需要照着下面的顺序把每一步跑通就能完成一次从构建到上架的完整提交流程。适合 iOS 开发工程师、独立开发者以及正在搭建 CI/CD 提审流水线的团队。文中涉及的命令和配置都是通用模板实际使用时按自己的项目和 Xcode 版本微调即可。1. 核心能力速览先说清楚这次要处理的东西是什么。iOS App 提交上架不是一个单一工具而是一套依赖 Apple 开发者账号、Xcode 构建工具链、App Store Connect 后台和第三方自动化脚本的完整流程。能力项说明主要目标完成 iOS App 的签名、构建、上传、TestFlight 内测、App Store 审核提交核心工具Xcode、xcodebuild、altool、Transporter、App Store Connect 网页后台、Fastlane可选必要账号Apple Developer Program 成员账号需要先在 Apple 开发者后台完成协议签署操作系统要求macOS建议使用能安装最新稳定版 Xcode 的系统版本签名体系开发证书、发布证书、App ID、描述文件、密钥文件自动签名支持 Xcode Automatically manage signing命令行上传支持 altool / Transporter便于脚本化自动化辅助Fastlane 可以批量管理多 App 构建、截图、元数据提交官方 APIApp Store Connect API可用于自动创建版本、查询构建、管理元数据内测分发TestFlight支持内部测试员和外部测试员投入成本Apple Developer Program 年费具体金额以 Apple 官网为准适合场景日常迭代发版、多 App 管理、需要减少重复手工操作的团队这里要提醒一句Xcode 和 macOS 的版本绑定关系比较严格。实际部署时先确认自己的 Xcode 版本能跑在哪个 macOS 版本上再决定升级顺序很少出现“直接升最新版”就能无痛切换的情况。2. iOS 提审全流程从开发到上架先建立一个全局视角。整个提审链路可以拆成 8 个阶段每个阶段有明确的产物和判断标准。阶段主要动作产物 / 结果1. 账号准备加入 Apple Developer Program签署协议开发者后台可访问2. 注册 App ID到开发者后台创建 App ID配置对应能力唯一 Bundle Identifier3. 证书创建开发证书和发布证书.cer 证书文件4. 描述文件认证到 App ID 和证书配置测试设备.mobileprovision 文件5. 工程签名Xcode 中选择 Team 和签名方式Archive 产物6. 构建上传使用 Xcode Organizer / altool / Transporter 上传App Store Connect 中出现构建版本7. TestFlight邀请测试员安装验证测试版本通过8. 提交审核填写元数据、隐私信息、审核备注并提交审核通过后上架从实际操作来说阶段 3 和阶段 4 现在大部分情况可以交给 Xcode 的自动签名处理不用手工去开发者后台点来点去。但理解它们之间的关系仍然重要否则一旦签名报错你很难判断是证书过期、描述文件不匹配还是 App ID 没配置对。判断一个 App 是否具备提审条件可以从三个角度检查代码是不是已经可以通过 Archive 构建构建产物能不能成功上传到 App Store ConnectTestFlight 版本能不能正常安装运行。这三关都过了下一步才需要考虑元数据和审核备注。3. 环境准备与前置条件这里给一份通用检查清单不写死具体版本号。原因很简单不同项目使用的 Xcode 版本差别很大容易因为版本假设导致读者照做失败。开始之前建议先确认以下内容一台可以运行 Xcode 的 macOS磁盘空间至少留出 40-60 GBXcode 本体、模拟器缓存和构建缓存都比较占空间。安装 Xcode并打开一次 Xcode它会自动补装必需的组件。打开“系统设置 开发者工具”或者在终端执行一次xcode-select -p确认 Xcode 命令行工具已经指向正确路径。一个已经加入 Apple Developer Program 的 Apple ID并且该账号能访问 App Store Connect。确认 App Store Connect 中的“协议、税务和银行业务”已经完成。第一次提交审核前这一步很容易被忽略。确认网络可以正常访问 Apple 开发者服务和 App Store Connect。如果你在公司内网要特别注意防火墙或 DNS 是否拦截了相关域名这类问题通常表现为“登录一直转圈”或“上传到一半断掉”。验证 Xcode 环境是否正常的命令xcode-select -p xcodebuild -version如果xcode-select -p返回的不是 Xcode 目录可以手动切换sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer有些团队会同时安装 Xcode 正式版和 Beta 版这种情况下命令行工具可能指向 Beta 版构建时容易踩到 API 或证书兼容性问题。更稳妥的做法是明确指定 Xcode 路径DEVELOPER_DIR/Applications/Xcode.app/Contents/Developer xcodebuild -version另外还要登录 Xcode 的账户并确认授权信息。在 Xcode 的“设置 Accounts”里添加 Apple ID点击“Manage Certificates”确认里面有可用的 Distribution 证书。Xcode 会自动把证书下载到本机钥匙串中。4. 证书、描述文件与签名配置4.1 三种常见证书证书类型用途常见有效期Apple Development 证书真机调试、开发包构建一般较短需要关注到期日Apple Distribution 证书上传 App Store / 打包分发一般 1 年到期需重新签发Apple Push Notification 证书 / Key推送服务按 Apple 后台实际配置证书到期是最常见的“提审前才发现”问题。平时写代码不会触发证书检查但一旦执行 Archive 或 Export签名工具就会校验证书链发现问题直接抛出 error。4.2 自动签名与手动签名对于多数项目Xcode 的自动签名已经够用。你只需要打开 Xcode点击项目 Target。选择 Signing Capabilities。勾选 Automatically manage signing。在 Team 下拉框里选择自己的开发者团队。确认 Bundle Identifier 与 App Store Connect 中创建的 App 的 Bundle ID 一致。手动签名适合复杂工程、多个 App 共用证书、或者企业在 CI 机器上统一管理签名材料。手动签名时需要在开发者后台手动生成 Distribution 证书和 App Store 描述文件然后在 Xcode 的 Build Settings 里指定 provisioning profile。从排错角度看大多数签名问题都出在 Team 选择错误、Bundle ID 不一致、证书不在钥匙串中、描述文件过期这几个点。可以先在 Xcode 里执行 Archive如果签名配置有问题Xcode 会在构建阶段直接给出提示。4.3 签名校验命令准备提审前可以在工程目录里用命令确认签名参数xcodebuild -showBuildSettings -scheme YourScheme \ -configuration Release \ DEVELOPMENT_TEAMXXXXXXXXXX \ PROVISIONING_PROFILE_SPECIFIERYour Profile Name这里的DEVELOPMENT_TEAM和PROVISIONING_PROFILE_SPECIFIER需要替换成自己的团队 ID 和描述文件名称。执行后重点看CODE_SIGN_IDENTITY、DEVELOPMENT_TEAM、PROVISIONING_PROFILE三项输出确认签名配置符合预期。如果要用脚本导出 ipa可以用xcodebuild -exportArchive。先准备好 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/string keydestination/key stringexport/string keysigningStyle/key stringautomatic/string /dict /plist导出命令xcodebuild -exportArchive \ -archivePath build/YourApp.xcarchive \ -exportPath build/export \ -exportOptionsPlist ExportOptions.plist生成的 ipa 会出现在build/export目录。看到 ipa 文件后签名这一步才算真正落地。5. 构建、归档与上传5.1 Archive 构建打开 Xcode选择目标设备为 “Any iOS Device (arm64)”然后执行xcodebuild archive \ -workspace YourApp.xcworkspace \ -scheme YourScheme \ -configuration Release \ -archivePath build/YourApp.xcarchive如果项目不是 workspace而是单工程把-workspace换成-project并指向 .xcodeproj 即可。Archive 构建成功后打开 Xcode 的 Window Organizer 可以看到这个归档包。归档包的日期、版本号、Bundle ID 要认真核对因为上传后 App Store Connect 会按版本号和构建号区分。5.2 上传构建产物上传方式有三种常用路径Xcode Organizer 里选择 Distribute App按 UI 提示上传。这种方式最直观。用 altool 命令行上传。macOS 新版本 Xcode 可能推荐用xcrun altool或者将 altool 替换为notarytool相关流程需要按实际 Xcode 版本检查。用 Transporter.app 上传 .ipa 文件。这里给一个 altool 的通用模板xcrun altool --upload-app \ --file path/to/YourApp.ipa \ --type ios \ --username your.apple.idexample.com \ --password keychain:AC_PASSWORD密码这里使用钥匙串条目引用避免在命令行里出现明文。第一次使用时需要先把 App 专用密码存到钥匙串。如果没有设置 App 专用密码Apple ID 会拒绝登录。上传成功后命令行会输出类似No errors uploading archive的信息同时 App Store Connect 的 TestFlight 页面会开始出现“正在处理”的构建版本。处理时间通常在几分钟到几十分钟不等具体看 Apple 服务端的排队情况。如果长时间停留在“处理中”状态不要重复上传同一个构建号先等一段时间再检查上传日志。5.3 构建版本号策略每次上传的构建号不能与现有版本号重复。实践中常见做法是使用日期 构建序号比如1.0.0 (2025060701)这样既能区分测试包也方便 CI 自动生成。如果是同一版本多次修复后重提也要递增构建号否则 App Store Connect 会拒绝接收。6. TestFlight 内测与提交前验证6.1 添加内部测试员上传完成后进入 App Store Connect TestFlight。内部测试员不需要 Beta App Review可以直接添加成员外部测试员需要提供邮箱并且首次提交需要经过 Beta 审核。内部测试组适合开发团队和 QA 使用流程是创建一个内部测试组。添加测试员邮箱。选择刚刚上传成功的构建版本。等待构建状态变成“可供测试”。测试员在 TestFlight 应用里会看到这个版本可以安装验证。这一步能提前发现崩溃、启动闪退、权限弹窗异常等问题比直接提审要安全得多。6.2 真机验证重点在提交审核前至少要到真机上过一遍以下场景冷启动和热启动是否正常。权限弹窗是否在明确的用户操作后弹出而不是启动时一次性要求所有权限。内购和订阅流程是否完整。登录态是否能在 App 内正常处理。低版本系统和最新系统上的布局是否出现明显问题。有无明显崩溃、卡死、白屏。审核团队最反感的是“点几步就崩溃”或者“权限说明与实际行为不符”。这类问题在 TestFlight 阶段就能发现就不要带上正式审核。6.3 崩溃日志和性能检查如果 TestFlight 版本安装后崩溃可以查看 Xcode 的 Window Devices and Simulators找到对应设备的 Crash Logs。也可以利用 App Store Connect 提供的崩溃信息稍后分析。更实用的是在 Archive 前用 Xcode 的 Instruments 跑一轮内存和 CPU 检查尤其是涉及图片编辑、音视频处理、数据迁移的重型功能避免审核过程中出现明显性能问题。7. App Store Connect 提审与审核备注7.1 提审前需要填写的核心内容内容项说明App 名称和副标题要和实际功能一致不能堆砌关键词版本号要和构建产物中的版本号一致截图必须能反映真实功能不能出现模拟数据或开发环境页面描述写明核心功能和主要用途隐私政策 URL必须真实可访问尤其是涉及用户数据的 AppApp 隐私按实际情况声明数据收集和使用情况审核备注给审核员的说明用于解释账号密码、测试路径、特殊配置等销售范围选择发布国家和地区年龄分级按内容实际情况填写包含广告和服务内容时要注意广告标识符如果集成了广告 SDK需要声明 IDFA 使用方式这里面最容易出问题的是截图和隐私信息。审核团队会把截图当作第一判断依据一旦截图与实际交互不符很容易被判为元数据不准确。隐私政策 URL 不能用临时地址越早准备越好。7.2 审核备注怎么写审核备注不是用来“说服审核员”的而是用来降低审核成本。写的时候说清楚测试账号或演示账号。需要审核员验证的核心功能路径。是否包含需要联网登录才能使用的功能。是否包含内购、订阅、买断对应的沙盒测试说明。如果 App 依赖外部硬件或配套设备说明验证方式。示例审核备注 1. 登录账号demoexample.com / Demo123456 2. 首页点击「扫码配网」按钮进入蓝牙配对流程。 3. 需要在真机上使用实体设备验证。如果没有设备可以跳过该步骤。 4. 内购商品使用沙盒账号测试请在测试环境中登录。如果 App 涉及账号体系一定确保测试账号在审核期间有效不要提审当天才创建第二天就过期。常见的审核被拒原因之一就是“审核团队无法登录”。7.3 提交审核在 App Store Connect 后台完成所有必填项后点击“添加以供审核”然后在“版本”页面点“提交以供审核”。提交后进入Waiting for review状态。这个状态可能持续数小时到数天具体时间不固定。不要在这个过程中反复修改构建版本否则会打断审核队列。8. 自动化提审Fastlane 与 App Store Connect API如果你一年只发两三个版本手动提审完全足够。但如果是多 App 或多环境团队手动操作会导致两个明显问题重复劳动多且容易漏配置。Fastlane 是目前 iOS 提审自动化主力工具之一可以管理证书、描述文件、截图、构建上传、元数据提交。它的工作方式是先安装 Ruby 环境和 fastlane gem然后通过Fastfile和Appfile定义 lane。先安装sudo gem install fastlane -NV或者用 Bundler 管理依赖在工程目录下创建 Gemfilesource https://rubygems.org gem fastlane然后执行bundle install初始化 Fastlanecd path/to/your/project fastlane init一个基础的上传 TestFlight lane 的 Fastfile 模板default_platform(:ios) platform :ios do desc 提交 TestFlight lane :beta do increment_build_number( build_number: Time.now.strftime(%Y%m%d%H%M) ) build_app( scheme: YourScheme, export_method: app-store-connect ) upload_to_testflight( skip_waiting_for_build_processing: true ) end end执行bundle exec fastlane ios betaFastlane 可以多 lane 组合比如先跑构建再跑截图再更新元数据最后提审。这类批量任务非常适合每天需要出包的内测流程。8.1 App Store Connect API官方还提供了 App Store Connect API适合自研流水线或与现有 CI 系统集成。需要先在 App Store Connect 后台生成 API Key并记录 Key ID、Issuer ID以及下载 .p8 私钥文件。私钥文件只下载一次要妥善保存。一个通用调用模板如下。实际接口路径和参数需要以 App Store Connect API 官方文档为准。import requests import jwt import time issuer_id your-issuer-id key_id your-key-id private_key_path ./AuthKey_YourKeyId.p8 with open(private_key_path, r) as f: private_key f.read() now int(time.time()) token jwt.encode( { iss: issuer_id, iat: now, exp: now 1200, aud: appstoreconnect-v1, }, private_key, algorithmES256, headers{kid: key_id}, ) headers { Authorization: fBearer {token} } url https://api.appstoreconnect.apple.com/v1/apps response requests.get(url, headersheaders, timeout30) print(response.status_code) print(response.json())这个示例的作用是验证 API Key 是否可用。拿到响应后再根据官方文档继续做创建版本、查询构建状态等操作。要注意API Key 权限范围在创建时指定生产环境不要使用具有全部权限的 Key建议按系统角色拆分。8.2 批量任务设计多 App 提审时批量任务的核心不是“同时上传一堆包”而是把每一项配置拆成可重复执行的步骤每个 App 一个目录包含 Bundle ID、App Store Connect App ID、签名 Team、Appfile 配置。用脚本读目录清单循环执行 fastlane lane。每次上传后记录返回的 build id 和上传结果。失败任务重试时要检查是不是已经上传过避免重复构建号。在 Fastlane 中同一套 lane 配合不同 Appfile 就能处理多 App。也可以在脚本里动态切换--env参数按环境加载不同配置。9. 审核被拒高频原因与排查iOS 审核被拒是正常流程的一部分关键是快速定位原因。常见问题可以归纳为下面几类问题现象可能原因排查方式解决方案登录不了或核心功能不可用测试账号失效、服务端环境异常用审核备注中的账号完整走一遍流程更新测试账号保证审核期间长期有效截图与实际功能不符元数据信息不准确对比截图和 App 实际页面重新截图并替换权限使用说明不透明隐私政策缺失或权限弹窗未说明用途检查 Info.plist 中的用途描述文案补充 usage description说明真实使用原因涉及用户内容但缺少举报机制UGC 场景未做内容管理检查是否有屏蔽、删除、举报入口补全UGC相关控制和审核界面功能过于简单不符合 App Store 最低功能要求检查 App 是否就是一个网页或单按钮补充真实功能或调整产品定位崩溃或闪退测试环境下执行崩溃查看崩溃日志和 TestFlight 反馈修复崩溃后递增构建号重新上传5.2 知识产权相关审核素材、图标、商标涉及第三方检查素材授权情况替换未授权素材或补充授权证明加急审核申请被拒理由不充分确认是否属于 Apple 认可的加急审核类型优先走正常提审流程避免滥用如果被拒先看 App Store Connect 里的 Resolution Center 审核信息。审核团队通常会给截图或日志。定位问题后需要修复并重新上传构建然后在 Resolution Center 或者新版本中回应审核信息。这里最重要的原则是不要为了过审隐藏功能或编造用途一旦被发现后果往往比被拒更麻烦。另外如果团队内有人处理多个 App 的提审建议建立一个“提审记录表”记录每个 App 上次提审时间、被拒原因、重新提交时间。可以避免同一个问题在不同版本里反复踩坑。10. 最佳实践与合规建议10.1 提审工程化建议第一次操作时所有流程手动跑通一遍再上自动化。自动化工具只能减少重复操作不能替代对签名的理解。保留一套最小可运行的发布配置固定一个专用发布机只安装必要依赖避免本机多个 Xcode 版本互相影响。模型文件、证书、描述文件、导出配置、脚本分目录管理不要堆在桌面或临时目录。构建号建议由脚本统一生成不要手工维护避免多端重复。上传和提审脚本要加日志每次执行记录时间、版本号、构建号、返回结果方便回查。Fastlane 执行时要关注 Apple 服务端的限流和认证错误失败重试要加延迟不要脚本一崩就无限循环重试。App Store Connect API 调用的权限要最小化API Key 不要提交到公共代码仓库。10.2 隐私与合规边界App 收集任何用户数据前都要在 App 隐私中如实声明。截图、测试账号、测试数据不得包含真实用户信息。涉及用户生成内容、图片上传、音视频处理等功能必须提供内容管理、举报和删除机制。涉及人脸、声音、IoT 硬件、网络设备控制等功能必须确保用户已授权设备使用权限并在界面中清楚告知控制动作。内购项目如果涉及虚拟商品和服务要按 App Store 审核指南使用应用内购买不要走第三方支付。不要试图通过换 Bundle ID、重复上架等方式绕过平台规则这类行为一旦被识别账号风险极高。测试数据和演示账号不应包含任何未授权的个人数据。10.3 提审前的最终检查单提交审核前最后三件事第一重跑一遍完整构建确认没有使用上一次的缓存产物。第二在 TestFlight 上安装最新构建按用户真实路径操作一轮。第三打开 App Store Connect 的版本页面对照检查截图、隐私政策、审核备注、内购沙盒账号是否都是最新的。结尾iOS App 提审流程本质上是一个标准化工程问题签名配置走对Archive 能出包上传后 TestFlight 能跑元数据和审核备注写清楚被拒时按证据而不是凭感觉修改。最容易踩的坑集中在两个地方证书和描述文件的生命周期管理以及审核备注里检测账号提前失效。把这个流程沉淀成团队检查单再配合 Fastlane 或 App Store Connect API 做自动化后续每次发版的体力活会大幅减少。建议先把本文中的手动流程完整走通一次再决定要不要上自动化。