以下为 Google Gemini 整理，仅略作修改。

如果你觉得 Google Play 是“狂野西部”（规则多但自动化程度高），那么 Apple App Store 就是“皇家宫殿”——审核人工介入深、对细节要求极高、甚至有点“洁癖”。

以下是基于 2025 年标准 的 iOS App Store 发布与更新实战指南。

⚠️ 第一部分：发布前必查（苹果的特殊红线）

在 iOS 上架，如果不注意以下三点，几乎 100% 会被拒审或卡住：

  1. 隐私清单 (Privacy Manifests)

    • 政策现状： 从 2024 年春季开始强制执行。你的 App 及引用的第三方 SDK（如 Firebase, Facebook SDK）必须包含隐私清单文件。
    • 后果： 如果缺失或描述不符，上传包时会直接报错，根本无法提交审核。

  2. App 完整性与“占位符”

    • Apple 极度讨厌“半成品”。
    • 绝对禁止： 按钮点了没反应、界面上出现 "Lorem Ipsum" 或 "Coming Soon" 字样、以及明显的 Beta 版标签。
    • 测试账号： 如果 App 需要登录，必须在后台填写测试账号和密码，并且确保该账号在审核期间能正常登入且数据有内容（不要给一个空荡荡的账号）。

  3. 邓白氏编码 (D-U-N-S Number)

    • 如果你是注册公司账号（$99/年），必须拥有 D-U-N-S 编码，且公司名称必须与 Apple 开发者账号名称完全一致（连标点符号都要一样）。

🍎 第二部分：从 0 到 1 创建并发布 App

iOS 的发布流程主要围绕 App Store Connect（ASC） 与 Apple Developer 两套系统完成：前者负责应用创建、版本上传和审核，后者负责应用身份、证书与签名配置。

1. 账号与证书准备

  • 注册： Apple Developer Program

  • 费用： $99 美元/年（需每年续费，过期后 App 将被下架）。

  • 核心职责：

    • Apple Developer：管理 Certificates、Identifiers、Profiles
    • App Store Connect：管理 App、版本、审核与上架

2. Certificates, Identifiers & Profiles（重点）

这是 iOS 发布流程中最容易出错、也最容易一次配置长期受益的部分。

2️⃣ Identifiers（App ID）

路径：

Apple Developer
→ Certificates, Identifiers & Profiles
→ Identifiers
→ +
→ App IDs

配置要点：

  • Bundle ID

    • 必须使用 Explicit
    • 示例：com.company.appname
    • 与工程代码中的 Bundle ID 必须完全一致，后续不要随意修改

  • Push Notifications

    • 正常勾选即可
    • 不要勾选 Broadcast Capability
    • 普通 App 的用户级通知（消息、提醒、分析结果等）均不需要 Broadcast 推送

  • Sign in with Apple

    • 仅使用苹果登录功能时，直接开启即可
    • 无需配置 Primary App ID
    • 无需配置 Server-to-Server Notification Endpoint
    • 高级配置仅用于多 App / 多平台共用登录体系，后续可再补充，不影响当前审核

  • 其他 Capabilities

    • App Groups / Associated Domains / Keychain Sharing 等按实际需求开启
    • 不确定用途的能力不要提前勾选
3️⃣ Certificates（证书）

证书用于证明谁有资格为 App 签名，是打包和上架的前置条件。

（1）生成 CSR（证书签名请求）

CSR 需在 macOS 的 钥匙串访问 中生成：

钥匙串访问
→ 左侧选择「登录」
→ 菜单栏：钥匙串访问
→ 证书助理
→ 从证书颁发机构请求证书…

填写规则：

  • 用户电子邮件地址：任意常用邮箱
  • 常用名称：如 YourName Apple Dev
  • CA 电子邮件地址：留空
  • 请求方式：存储到磁盘

生成文件：

CertificateSigningRequest.certSigningRequest

必须在「登录」钥匙串中生成，确保后续证书能正确绑定私钥。

（2）创建证书类型

路径：

Certificates
→ +

常用证书：

  • Apple Development

    • 用于真机调试

  • Apple Distribution

    • 用于 TestFlight / App Store 上架（必须）

上传 CSR → 下载证书 → 双击安装即可。

4️⃣ Profiles（描述文件）

描述文件用于将 App ID + 证书 +（设备） 进行绑定。

常用类型：

  • iOS App Development

    • 用于开发与真机调试
    • 需要绑定设备

  • Ad Hoc（可选）

    • 内测分发给指定设备

  • App Store

    • 用于 TestFlight / App Store
    • 不需要绑定设备

3. 在 App Store Connect 创建应用

  1. 登录 App Store Connect

  2. 点击 “我的 App（My Apps）” → “+” → “新建 App”

  3. 填写信息：

    • 名称： App Store 显示名（≤ 30 字符）
    • Bundle ID： 与工程 Bundle ID 完全一致
    • SKU： 内部唯一标识（如 app_ios_v1）

4. 填写元数据（Metadata）

  • 关键词（Keywords）

    • 总长度 ≤ 100 字符

    • 使用英文逗号分隔，不加空格
      例如：

      行情,交易,提醒,智能分析

  • 技术支持网址（Support URL）

    • 必须提供一个可访问的网页

  • 屏幕截图（Screenshots）

    • 必须包含：

      • 6.5 英寸
      • 5.5 英寸

    • 不得出现 Android 设备、非苹果 UI 或误导性文案

  • App 隐私（App Privacy）

    • 按实际数据收集情况填写
    • 内容必须与真实行为一致

5. 上传构建版本（Build）

  • 上传方式：

    • Xcode（推荐）
    • Transporter（Apple 官方工具）

  • 处理时间：

    • 上传后状态为 Processing
    • 通常 10–30 分钟完成
    • 处理完成后需手动选择该 Build

  • 出口合规信息：

    • 使用加密：是
    • 是否仅使用标准加密（HTTPS / TLS）：是
    • 是否需要额外文件：否

6. 提交审核（Submit for Review）

  • 在版本页面点击 Add for Review

  • 确认 Build 已选择、信息无缺失

  • 提交审核即可

  • 审核时间：

    • 通常 24–48 小时
    • 周末也会审核，但速度略慢

🔄 第三部分：后续版本更新操作 (Routine Update)

iOS 的更新比 Google Play 直观，但更“手动”。

1. 版本号管理

  • Version (营销版本)： 如 1.2.0。这是用户在商店看到的。
  • Build (构建版本)： 如 5 或 20251122。
  • 运维规则： 每次上传新包到后台，Build 号必须递增。但 Version 号只需要在发布新功能时改变。

2. 创建新版本

  1. 在 App Store Connect 首页，点击你的 App。
  2. 左侧栏上方会出现 "iOS App 1.x 准备提交"（如果没有，点 "+" 号创建新版本）。
  3. 更新版本号： 填入新的 Version（如 1.2.1）。
  4. 此版本的新增功能 (What's New)： 必填。告诉用户更新了什么。

3. 选择构建版本

  • 在 "构建版本" (Build) 区域，点击 "+" 号，选择开发人员刚上传的最新包。
  • 注意：如果开发刚传完，可能要等几分钟才能刷出来。

4. 灰度发布 (Phased Release) —— 运维关键点

Apple 的灰度发布机制叫 "分阶段发布 (Phased Release for Automatic Updates)"。

  • 如何开启： 在“版本发布”部分的选项里勾选 "使用分阶段发布"。
  • 机制： 无法像 Google 那样自定义百分比。Apple 固定按 7 天周期放量：
    • Day 1: 1%
    • Day 2: 2%
    • Day 3: 5%
    • Day 4: 10%
    • Day 5: 20%
    • Day 6: 50%
    • Day 7: 100%
  • 作用： 如果发现重大 Bug，随时点击 "暂停分阶段发布"，此时未更新的用户将不会收到推送。

5. 提交与发布方式

  • 手动发布 (Manually)： 审核通过后，App 状态变为 "Pending Developer Release"。你需要上来点一下 "Release" 才会上架。（推荐运维使用，可控性强）。
  • 自动发布 (Automatically)： 审核一通过，立即上架。

📝 运维专家的小抄 (Cheat Sheet)

检查项说明
TestFlight正式发布前的神器。上传包后，先推给 TestFlight 内部测试，无需审核即可安装，验证无误后再提审。
分辨率中心 (Resolution Center)如果被拒，消息会发到这里。千万不要重新提交新包来“试错”，要在里面直接回复审核人员进行申诉或解释。
加急审核 (Expedited Review)如果有导致 App 崩溃的严重 Bug，可以申请“加急”。链接比较隐蔽，且不能滥用（一年一般只有 1-2 次机会）。
元数据被拒 (Metadata Rejected)这是最好的拒审理由。说明包本身没问题，只是截图或文案有问题。改一下文案，不需要重新打包，直接回复即可过审。
4.2.3 拒审 (Minimal Functionality)很多简单套壳 App 会死在这里。Apple 认为你的 App 功能太简单，仅仅是个网页浏览器。

附录：iOS Xcode 打包

补充 Xcode 上传 这一环节非常关键。很多时候代码写好了，却因为“打包上传”这个动作卡住，导致无法按时发版。

对于运维或发布人员来说，通常有两种情况：

  1. 开发人员给源码，你需要在自己的 Mac 上编译并上传。
  2. 开发人员给 .ipa 文件，你只需要负责上传。

下面我重点讲解 场景 1：使用 Xcode 从源码直接编译并上传到 App Store Connect 的完整标准流程。

🛠️ 前置条件 (Prerequisites)

在打开 Xcode 之前，请确认：

  • Mac 设备： 必须是 macOS 系统。
  • Apple ID 权限： 你的账号在 App Store Connect 中必须有 "App Manager" (App 管理员) 或更高权限。
  • 证书配置： Xcode 的 Settings -> Accounts 中已登录开发者账号，且本地已下载好发布证书（Distribution Certificate）。

🚀 Xcode 打包上传五步走

第一步：检查版本号与构建设置

在 Xcode 左侧的文件导航栏，点击最顶部的蓝色项目图标（Project Navigator）：

  1. 选择 Targets（通常是你的 App 名字）。
  2. 进入 General 选项卡。
  3. Identity 部分（核对红线）：
    • Bundle Identifier: 必须和 App Store Connect 后台建的 App ID 一致。
    • Version: 比如 1.2.0（对用户展示）。
    • Build: 比如 202502（必须比上一次上传的数字大）。
  4. Signing & Capabilities: 确保 "Signing (Release)" 勾选了 "Automatically manage signing"（除非你们公司强制要求手动配置 Provisioning Profile）。

第二步：选择编译设备 (Any iOS Device)

这是新手最容易报错的地方。

  • 在 Xcode 顶部工具栏，左上角的设备选择器中。
  • 不要选模拟器（如 iPhone 15 Simulator）。
  • 必须选： "Any iOS Device (arm64)" 或者你插在电脑上的真机。
    • 如果不选真机/Any Device，"Archive" 按钮是灰色的，点不了。

第三步：执行归档 (Archive)

这是将代码编译成 App 的过程。

  1. 点击顶部菜单栏的 Product。
  2. 选择 Archive。
  3. 等待： 也就是所谓的“编译时间”，根据项目大小，可能需要 3 分钟到 30 分钟不等。

第四步：在 Organizer 中分发 (Distribute)

编译完成后，Xcode 会自动弹出一个叫 "Organizer" 的窗口（如果没有弹，点击 Window -> Organizer）。这里会列出所有的历史归档记录。

  1. 选中刚刚生成的那个记录（最新的一条）。
  2. 点击右侧的蓝色按钮 "Distribute App"。
  3. 选择分发渠道：
    • 选 "App Store Connect" -> Next。
    • 选 "Upload" (上传) -> Next。（不要选 Export，Export 是导出 ipa 用的）。
  4. 配置选项 (App Store Connect options)：
    • Upload your app's symbols (dSYM): 必须勾选。否则 Crashlytics 抓不到具体的崩溃代码行数。
    • Manage Version and Build Number: 建议不勾选（以你代码里写的为准）。如果勾选，Xcode 会试图自动修改你的版本号，容易乱。
  5. 签名确认 (Re-sign):
    • 选择 "Automatically manage signing" -> Next。
    • 系统会联网验证证书，如果一切正常，会显示一个包含所有信息的“Summary”页面。

第五步：上传 (Upload)

  1. 点击 "Upload" 按钮。
  2. Xcode 会开始上传二进制文件、验证 API 用法等。
  3. 成功： 出现绿色的勾，显示 "App "Name" was successfully uploaded"。

💡 运维专家的“B 计划”：如果 Xcode 上传总是失败？

Xcode 上传非常依赖网络稳定性，且 UI 比较卡顿。作为运维，我强烈推荐你使用 Transporter。这是 Apple 官方推出的专门用于上传 ipa 的轻量级工具。

这种方式更适合运维人员（开发给 ipa，你来传）：

  1. 获取 ipa： 在上述 Xcode 流程的第四步，选择 "Export" 而不是 "Upload"，导出一个 .ipa 文件。
  2. 下载 Transporter： 在 Mac App Store 免费下载。
  3. 操作：
    • 打开 Transporter，登录 Apple ID。
    • 把 .ipa 文件直接拖进去。
    • 点击 "Deliver" (交付)。
  4. 优势： Transporter 的进度条更真实，网络报错信息更详细，且传输速度通常比 Xcode 快且稳。

📝 常见报错与解决 (Troubleshooting)

报错提示原因解决方法
"Redundant Binary Upload"版本号重复了。你正在上传一个后台已经存在的 Build 号。去 Xcode 改大 Build 号（如 100 改为 101）重新 Archive。
"Invalid Code Signing"证书不对。检查 Signing 设置，确保发布用的是 Distribution 证书，而不是 Developer 证书。
"Missing Info.plist key..."缺少权限描述。比如你用了相机，但没在 Info.plist 里写 NSCameraUsageDescription。根据提示补上描述即可。
ITMS-90809: Deprecated API Usage使用了过期 API。比如上传时包含 UIWebView。这是硬伤，必须让开发修改代码，移除旧 API。