iOS 应用从 0 到 App Store 上线：一份可复用的发布清单

这篇文章记录的是一条可重复执行的发布路径。Apple 的审核规则和后台界面会持续调整，实际提交前应再核对当时的官方要求。本文更新时间：2026-08-09。

先明确：上线不是最后点一次按钮

一次完整的 iOS 上线至少包含四条链路：开发者账号与权限、应用标识与签名、构建与上传、商店资料与审核。很多问题并不是出在代码，而是四条链路中的信息没有对齐。

我通常先建立一张发布检查表，把负责人、账号、Bundle ID、版本号、构建号、隐私信息、审核状态和发布时间放在同一处。这样遇到审核退回时，可以快速定位是包、资料还是账号问题。

上线前准备

账号与权限

可用的 Apple Developer Program 团队账号。
App Store Connect 中至少具备创建应用、上传构建和提交审核所需的角色。
团队名称、公司主体和联系信息已经确认。
双重认证设备可用，避免发布窗口临时找不到验证码。

不要共享个人 Apple ID。多人协作时通过 Users and Access 分配角色，并在人员变化后及时回收权限。

应用身份

准备一个长期稳定的 Bundle ID，例如：

com.company.product

Bundle ID 一旦与线上应用绑定，后续迁移成本很高。命名时不要把测试环境、年份或临时项目代号写进去。测试版可以通过构建配置使用独立后缀，但正式应用身份应保持稳定。

发布素材

应用名称、副标题、关键词和描述。
隐私政策 URL、技术支持 URL。
应用图标与各设备尺寸截图。
审核联系人、演示账号和必要的操作说明。
数据采集、第三方 SDK 与权限用途清单。

第一步：创建 Identifier 与能力

在 Certificates, Identifiers & Profiles 中创建 App ID，并确保 Bundle ID 与工程完全一致。然后只开启实际使用的能力，例如 Push Notifications、Associated Domains、Sign in with Apple 或 App Groups。

能力配置必须同时在三个地方对齐：开发者后台、Xcode Target 的 Signing & Capabilities、最终的 entitlements 文件。只在其中一处开启，通常会在归档或安装阶段报错。

第二步：确定签名策略

小团队可以优先使用 Xcode 自动签名，降低证书和描述文件维护成本。CI、多团队或有严格权限隔离的项目，更适合手动管理 Distribution 证书和 App Store Provisioning Profile。

发布前确认：

Release 配置选择正确的 Team。
Bundle ID 与 App Store Connect 建档一致。
Distribution 证书未过期。
Provisioning Profile 包含当前证书与能力。
Keychain 中的证书包含可用私钥。

常见的 No signing certificate、Provisioning profile doesn't include 和 capability 不匹配，基本都可以沿这五项排查。

第三步：在 App Store Connect 建档

创建新 App 时需要填写平台、名称、主要语言、Bundle ID、SKU 和访问范围。SKU 只用于内部识别，建议使用稳定且可读的规则，例如：

PRODUCT-IOS-PROD

App Store Connect 应用列表

建档后先完成 App Information、Pricing and Availability、App Privacy 等不会依赖构建包的部分。这样上传构建后，剩余工作更集中。

第四步：准备 Release 构建

正式归档前统一版本号与构建号：

CFBundleShortVersionString：面向用户的版本，例如 2.0.42。
CFBundleVersion：每次上传必须递增的构建号。

React Native 项目还要确认 JS Bundle、Source Map 和原生符号文件对应同一次构建。不要在归档后重新打 JS 包，否则线上堆栈可能无法正确还原。

建议先在真机 Release 模式完成一次最小回归：启动、登录、核心列表、图片上传、推送、深链、支付或企业业务中的关键流程。

第五步：Archive 与上传

在 Xcode 中选择 Generic iOS Device 或真实设备，然后执行 Product → Archive。归档完成后在 Organizer 中先运行 Validate App，再执行 Distribute App。

上传前重点查看验证结果：

是否包含不允许的私有 API。
图标和启动资源是否缺失。
签名与 entitlements 是否一致。
最低系统版本与架构是否符合预期。
隐私清单和第三方 SDK 声明是否完整。

上传成功不代表立即可选。App Store Connect 处理构建通常需要一段时间，处理完成后才能绑定到版本。

第六步：TestFlight 验证

不要跳过 TestFlight。至少安排一轮内部测试，验证安装、升级、登录、推送、网络权限和生产环境接口。

测试时记录三类信息：设备与系统版本、应用版本与构建号、具体操作路径。只有“打不开”而没有这些上下文，排查效率会很低。

第七步：填写版本资料与隐私信息

选择本次构建后，补齐版本描述、关键词、截图、支持网址、营销网址和审核信息。如果应用需要登录，应提供长期有效的审核账号，并关闭验证码、地域限制等会阻断审核的条件。

隐私信息要与真实行为一致：

收集哪些数据。
数据是否与用户身份关联。
数据是否用于跟踪。
权限弹窗之前是否有清晰的用途说明。

只复制别的应用答案风险很高。最稳妥的做法是从代码、第三方 SDK 和服务端接口反向核对。

第八步：提交审核与发布策略

提交前做一次最终检查：构建号、版本资料、隐私问卷、出口合规、内容分级、审核账号和发布方式。

发布方式通常有三种：审核通过后自动发布、手动发布、分阶段发布。企业业务或需要配合后端变更时，我更倾向手动发布，先确认服务端、配置和监控准备完成，再开放新版本。

常见审核问题

审核账号不可用

审核期间不要重置密码或关闭账号。涉及组织、角色或特定数据时，提前准备可复现的演示环境和说明。

权限用途描述过于笼统

需要您的相机权限 信息不足。应该说明用户在哪个动作中、为了什么业务目的使用相机，例如扫码收货或上传凭证。

后台功能与描述不一致

截图、描述和实际功能要对应。未开放的功能不要提前写进商店资料，灰度能力也要确保审核账号可见。

构建上传后无法选择

依次检查构建是否仍在处理、协议是否待签署、加密出口问题是否未回答、版本号是否与当前页面一致。

上线后的验证清单

App Store 页面、图标、截图和版本号正确。
新用户可以正常下载、安装和首次启动。
老用户升级后本地数据与登录态正常。
生产接口、推送、深链和文件能力正常。
Sentry 或其他监控平台已识别新版本。
Source Map、dSYM 与构建号可以对应。
客服、运营和后端知道本次变更与回滚方案。

最后沉淀一份发布记录

每次发布结束后记录版本、构建号、提交时间、通过时间、审核问题、线上异常和处理动作。发布记录不是形式工作，它会在下次审核被拒或紧急回滚时直接节省时间。