重新上传 iOS 应用到 App Store

如果你刚开始接触 iOS 发布流程，建议先阅读重新上传 iOS 构建到 TestFlight——前置要求完全相同（Mac、Xcode、Apple Developer Program 开发者账号、App Store Connect 应用记录）。App Store 流程假设你的应用已经在商店上线，本教程只涉及发布更新版本。

如果这是你第一次提交 App Store，流程大体相似，但还需要完成初始应用元数据的创建。Apple 官方首次提交指南 ↗ 有详细说明；完成后再回到本教程，了解后续更新上传的流程。

与 TestFlight 上传相同。在 Xcode → 目标 → General → Identity 中：

• Version（CFBundleShortVersionString）——需要更新。公开版本应有明确的版本变化（例如 1.2.0 → 1.3.0 或 1.2.1）。
• Build（CFBundleVersion）——在原有基础上加 1。

Apple 要求 App Store 提交必须包含真实的 Version 变更。"1.2.0 → 1.2.0" 会被拒绝；"1.2.0 → 1.2.1" 或 "1.2.0 → 1.3.0" 均可通过。

CFBundleShortVersionString 文档 ↗ · 语义化版本规范入门 ↗。

与 TestFlight 完全相同：

• 将目标设备设置为 Any iOS Device (arm64)。
• 点击菜单 Product → Archive。
• 在 Organizer 窗口中：先点击 Validate App（可提前发现签名/权限问题）。
• 然后点击 Distribute App → App Store Connect → Upload。

也可使用其他上传工具：Transporter 应用 ↗（拖入 IPA，点击 Deliver）或带有 App Store Connect API 密钥 的 xcrun altool。

完整的归档/上传流程请参阅重新上传 iOS 构建到 TestFlight。

Apple 处理构建通常需要 5–30 分钟。可在 App Store Connect ↗ → 你的应用 → TestFlight 标签页中查看进度。当新构建显示状态为 Ready to Submit 时，即可将其关联到 App Store 版本。

在 App Store Connect → 你的应用 → 左侧边栏 App Store 标签页中操作。

点击版本下拉框旁边（左上角）的 + Version 按钮，输入新版本号（例如 1.2.1）——必须与构建包中的 CFBundleShortVersionString 完全一致。

这会创建一个新的"版本页面"，你需要在此填写信息并提交。

在新版本页面中向下滚动，找到 Build 区域，点击 +（Add Build），选择刚刚上传的构建。

如果构建未出现，说明处理尚未完成——稍等几分钟后刷新页面。

在 What's New in This Version 字段中填写面向用户的更新说明。这些内容会显示在 App Store 的版本更新页面。

好的更新说明应该：

• 具体——"修复了离线状态下打开设置时的崩溃问题"胜过"修复了 Bug"。
• 简洁——最多 3–5 条要点。
• 以用户为中心——描述效果，而非实现细节。"项目加载更快"胜过"重构了项目解析器"。

如果你的应用支持多语言，请为每种语言分别填写更新说明。App Store 本地化文档 ↗。

并非每次发布都需要更新截图、描述和关键词——只有在用户可见的内容发生明显变化，需要新图片来展示时才更新。

如果确实需要更新截图：

• 必需尺寸——至少提供一套 iPhone 截图（最新机型为 6.7" 或 6.9"）。如果支持 iPad，也需提供 iPad 截图。最新截图规格说明 ↗。
• 截取方式——Xcode → Window → Devices and Simulators → 在模拟器中截图；或使用 fastlane snapshot ↗ 自动化截图。
• 添加设备外框（可选）——可使用 fastlane frameit ↗ 或 Shotbot ↗ 为截图添加设备边框和文字覆盖层。

你还可以更新：描述、关键词（总计 100 个字符，以逗号分隔）、支持 URL、营销 URL、宣传文本（170 个字符，无需重新提交即可随时修改）。这些内容不是必须的，但定期更新有助于维持应用的新鲜度。

向下滚动到 Version Release 区域，有三种选项：

• 手动发布此版本——审核通过后，更新会停留在"待开发者发布"状态，直到你手动点击发布按钮。适合需要协调上线时间的发布。
• 自动发布此版本——Apple 审核通过后立即上线。适合常规更新。
• 审核通过后，通过分阶段发布自动推送更新——在 7 天内分批次向用户推送（第 1 天 1%，随后依次为 2%、5%、10%、20%、50%、100%）。适合风险较高的更新，可在全量推送前发现潜在问题。

对于大多数更新，分阶段发布是最稳妥的默认选择。如果发现问题，可以在任意百分比处暂停推送。分阶段发布文档 ↗。

App Store Connect 会展示一份需要确认的事项清单，重点关注以下几项：

• 隐私政策 URL——必填项，且链接必须可正常访问。
• 应用隐私——数据收集披露信息。若新增了跟踪或数据收集功能，需更新此项。应用隐私文档 ↗。
• 年龄分级——若内容有变更，需重新填写。
• 出口合规——通常沿用构建包的设置。加密出口合规文档 ↗。
• 内容版权——确认你对应用中的所有内容拥有相应权利。

当所有必填项都显示绿色对勾后，右上角的 Add for Review 按钮将变为可点击状态。点击它，版本状态将变为 Waiting for Review。

然后点击 Submit to App Review。版本状态的流转为：Waiting for Review → In Review → Pending Developer Release（手动发布）或 Ready for Sale（自动发布）。

App Store 审核时间参考：

• 约 24 小时——典型情况（根据 Apple 官方公布的数据 ↗）
• 1–3 天——正常更新的实际等待范围
• 最长 7 天——首次提交、较大改动或涉及边缘内容的情况

如果被拒，你会在 Resolution Center（App Store Connect → 你的应用 → 顶部导航）收到说明拒绝原因的消息。可回复修复方案或解释说明后重新提交。大多数拒绝情况一次修改即可解决。

• 指南 4.0 – 设计 / 4.3 – 设计抄袭——与现有应用或通用模板过于相似。较少见，通常针对模板化应用。
• 指南 2.1 – 性能：应用完整性——审核期间崩溃、登录流程失效、内容占位符未替换——审核员无法正常使用应用。最常见的拒绝原因。
• 指南 5.1.1 – 隐私——收集了未在应用隐私中声明的数据；缺少隐私政策。
• 指南 3.1.1 – 应用内购买——数字商品未使用 IAP，或尝试将用户引导至外部支付渠道。
• 元数据拒绝——截图显示的应用与实际提交的不符；描述中出现竞品名称；宣传文本声称了不支持的功能。

完整审核规则请参阅：App Store 审核指南 ↗。

发布后，持续关注销量、下载量和崩溃率：

• App Store Connect → Analytics——查看下载量和收入。
• Xcode Organizer → Crashes 标签页——查看按堆栈跟踪分组的崩溃报告。
• Xcode Organizer → Metrics——监控启动时间、电池使用和滚动性能。

如果你选择了分阶段发布，而 Crashes 显示新版本存在性能回退，可以在 App Store Connect 中暂停分阶段推送，或提交一个紧急修复版本。