axiom-app-store-submission

App Store 提交

概述

系统化的提交前检查清单，可在提交前发现 90% 的 App Store 拒绝原因。核心原则：一次提交，提交到位。超过 40% 的 App Store 拒绝都涉及指南 2.1（App 完整性）——崩溃、占位内容、失效链接。另有 30% 与元数据和隐私问题有关。严格执行提交前检查流程，可避免这些本可预防的拒绝。

关键见解：Apple 在 2024 年拒绝了近 193 万次提交。大多数拒绝并非源于政策分歧，而是检查清单执行不到位。花 30 分钟进行提交前检查，可省去 3–7 天的拒绝、修复和重新提交周期。

何时使用此技能

✅ 在以下情况下使用此技能：

• 准备向 App Store 提交应用或更新
• 作为新开发者提交首个应用
• 回复 App Review 的拒绝结果
• 在 TestFlight 或正式发布前进行提交审核
• 长时间间隔后更新现有应用（可能适用新要求）
• 想知道“我的应用可以提交了吗？”

❌ 以下情况请勿使用此技能：

• 代码签名和配置描述文件（请使用 build-debugging）
• CI/CD 流水线设置
• 性能优化（请使用 ios-performance）
• UI 测试自动化（请使用 ui-testing）
• App 内购买项目实现（请使用 storekit-ref）
• 隐私清单详情（如需深入了解实现，请使用 privacy-ux）

示例提示词

开发者常问的真实问题，此技能可为其解答：

1. “我的应用可以提交到 App Store 了吗？”

此技能提供完整的提交前检查清单，涵盖构建、隐私、元数据、账户、审核信息、内容和地区要求

2. “提交首个 iOS 应用前需要准备什么？”

此技能从零开始逐项说明所有要求——隐私清单、元数据字段、屏幕截图、演示凭据、年龄分级

3. “我的应用一直被拒绝，是遗漏了什么？”

此技能列出反模式和具体拒绝原因，并提供用于识别遗漏项的决策树

4. “App Store 提交前检查清单有哪些内容？”

此技能提供分类的必备检查清单，列出所有缺失时会触发拒绝的项目

5. “我需要隐私清单吗？”

需要。自 2024 年 5 月起，缺少隐私清单会导致自动拒绝。此技能说明了适用情形和操作方法。

6. “我的应用更新因元数据问题被拒绝了”

此技能介绍元数据完整性要求，以及常见的遗漏问题，这些问题会触发指南 2.3 的拒绝

---

反模式

1. 未在设备上测试就提交

时间成本：3–7 天（拒绝 + 修复 + 等待重新提交）

症状：因指南 2.1——App 完整性而被拒绝。App Review 发现应用崩溃、流程中断或功能缺失。

❌ 不佳：只在 Simulator 中测试，构建成功后就提交

"It works in Simulator, ship it"
→ Rejection: App crashes on launch on iPhone 15 Pro (memory limit)
→ 3-7 day delay

✅ 良好：在搭载最新正式版 OS 的实体设备上测试，并走遍所有用户流程

# Build for device
xcodebuild -scheme YourApp \
  -destination 'platform=iOS,name=Your iPhone'

# Test critical paths:
# - Launch → main screen loads
# - All tabs/screens accessible
# - Core user flows complete without crash
# - Edge cases: no network, low storage, interruptions

有效原因：Simulator 无法呈现真实设备的限制——内存限制、蜂窝网络行为、硬件专属 API、热降频。App Review 会在实体设备上测试。

2. 隐私政策缺失或不完善

耗时：2-5 天（被拒 + 创建政策 + 重新提交）

症状：因 Guideline 5.1.1(i) — 数据收集与存储而被拒。隐私政策缺失、无法访问，或与实际数据实践不一致。

❌ 不佳：没有隐私政策 URL，或使用与实际数据收集情况不符的通用模板

Privacy Policy URL: (empty)
— or —
Privacy Policy: "We respect your privacy" (generic, no specifics)

✅ 良好：隐私政策可通过两处访问，且针对应用的数据实践进行了具体说明

1. App Store Connect → App Information → Privacy Policy URL
2. In-app → Settings/About screen → Privacy Policy link
3. Policy content lists:
   - All collected data types
   - How each type is used
   - Third-party sharing (who and why)
   - Data retention period
   - How to request deletion

三方一致性：Apple 会比较 (a) 应用的实际行为、(b) 隐私政策内容，以及 (c) ASC 中的隐私营养标签。三者必须一致。如果其中任何一项不一致，就会因 5.1.1 被拒。请查看每个 SDK 的文档，了解其隐私清单和数据收集披露信息——应用收集的数据总量等于你的代码加上所有 SDK 收集的数据。

为何有效：Guideline 5.1.1(i) 要求隐私政策既可在 ASC 元数据中访问，也可在应用内访问。政策必须具体说明应用的数据实践，而不能使用通用模板。

---

3. 构建版本中残留占位内容

耗时：3-5 天（被拒 + 替换内容 + 重新提交）

症状：因 Guideline 2.1 — 应用完整性而被拒。审核人员发现占位文本、空白屏幕或 TODO 遗留内容。

❌ 不佳：发布的应用中仍有用户可见的开发遗留内容

- "Lorem ipsum" text in onboarding
- Empty tab that shows "Coming Soon"
- Button that opens alert "Not implemented yet"
- Default app icon (white grid)

✅ 良好：每个屏幕都包含最终内容和正式资源

Pre-submission content audit:
- [ ] Every screen has real content (no lorem ipsum)
- [ ] All images are final production assets
- [ ] No "Coming Soon" or "Under Construction" screens
- [ ] All buttons perform their intended action
- [ ] Default/empty states have proper messaging
- [ ] App icon is final and meets spec (1024x1024, no alpha)

为何有效：App Review 会测试每个屏幕和标签页，包括你可能认为属于边缘情况的状态。他们会打开每个菜单、点击每个按钮并切换每个标签页。

---

4. 忽略隐私清单

耗时：1-3 天（自动拒绝 + 创建清单 + 重新提交）

症状：在人工审核前自动被拒。缺少 PrivacyInfo.xcprivacy，或未声明 Required Reason API。

❌ 不佳：没有隐私清单，或缺少 Required Reason API 声明

No PrivacyInfo.xcprivacy in project
— or —
Using UserDefaults, file timestamps, disk space APIs
without declaring approved reasons

✅ 良好：包含隐私清单，并声明所有 Required Reason API

Project must contain:
├── PrivacyInfo.xcprivacy
│   ├── NSPrivacyTracking (true/false)
│   ├── NSPrivacyTrackingDomains (if tracking)
│   ├── NSPrivacyCollectedDataTypes (all types)
│   └── NSPrivacyAccessedAPITypes (all Required Reason APIs)
│
└── Third-party SDK manifests (each SDK includes its own)

需要声明的常见 Required Reason API：

• UserDefaults → Reason CA92.1
• 文件时间戳 API → Reason C617.1
• 磁盘空间 API → Reason E174.1
• 系统启动时间 → Reason 35F9.1

为何有效：自 2024 年 5 月起，这是一项自动化门槛。无需人工审核——构建处理系统会拒绝缺少必要隐私声明的提交。

---

5. 缺少 Sign in with Apple

耗时：3-7 天（实现 SIWA + 重新提交）

症状：因 Guideline 4.8 被拒。应用提供第三方登录（Google、Facebook、电子邮件），但没有 Sign in with Apple 选项。

❌ 不佳：提供第三方登录，但不提供 SIWA

// Login screen offers:
// - Sign in with Google
// - Sign in with Facebook
// - Email/password
// ← Missing: Sign in with Apple

✅ 良好：提供 SIWA，作为与任何第三方登录等效的选项

// Login screen offers:
// - Sign in with Apple ← Required if others exist
// - Sign in with Google
// - Sign in with Facebook
// - Email/password

例外情况（无需 SIWA）：

• 公司内部或仅供员工使用的应用
• 使用现有学校账户的教育类应用
• 要求政府身份证件的政府、税务或银行类应用
• 作为特定第三方服务客户端的应用
• 仅使用公司自有身份验证系统的应用

为何有效：Guideline 4.8 要求只要提供任何第三方或社交登录，就必须提供 SIWA 作为选项。Apple 会严格执行此要求。

---

6. 没有账户删除流程

耗时：5-10 天（实现 + 测试 + 重新提交）

症状：因 Guideline 5.1.1(v) 被拒。应用允许创建账户，却没有提供删除账户的方式。

❌ 不佳：允许创建账户，但不支持删除

- Sign up button exists
- No "Delete Account" anywhere in app
- "Contact support to delete" (not sufficient)
- "Deactivate account" (not the same as delete)

✅ 良好：在应用内提供完整的账户删除流程

Account deletion requirements:
1. Discoverable in Settings/Profile (not hidden)
2. Clearly labeled "Delete Account" (not "Deactivate")
3. Explains what deletion means (data removed, timeline)
4. Confirms completion to user
5. If Sign in with Apple used → revoke SIWA token
6. If active subscriptions → inform user to cancel first
7. Deletion completes within reasonable timeframe (days, not months)

// Revoking Sign in with Apple token (required)
let appleIDProvider = ASAuthorizationAppleIDProvider()
let request = appleIDProvider.createRequest()

// After user confirms deletion:
// POST to Apple's revoke endpoint with the user's token
// Then delete server-side account data

为何有效：自 2022 年 6 月起，此项要求已生效。必须实际删除账户（而非停用），必须在应用内提供此功能（不能只通过电子邮件或网站处理），并且如果使用了 SIWA，还必须撤销 SIWA 令牌。Apple 会专门测试此流程。

---

7. 年龄分级错误

耗时：2-4 天（重新回答问卷 + 可能需要修改内容 + 重新提交）

症状：因 Guideline 2.3.6——元数据不准确而被拒。年龄分级未能反映应用的实际内容或功能。

❌ 错误做法：低报内容以获得较低分级

App has user-generated content (chat, posts)
but age rating questionnaire answered "No UGC"

App has cartoon violence in gameplay
but answered "No violence"

✅ 正确做法：如实填写年龄分级问卷

Declare honestly:
- User-generated content (chat, forums, social features)
- Violence (even cartoon/fantasy)
- Mature themes
- Profanity / crude humor
- Gambling (simulated or real)
- Horror / fear themes
- Medical / treatment information
- Unrestricted web access (WebView with open URLs)

更新后的年龄分级（自 2026 年 1 月 31 日起生效）：Apple 将原有的 4+/9+/12+/17+ 扩展为 5 个等级（4+/9+/13+/16+/18+），并新增了有关消息、UGC、广告和家长控制的功能声明。所有开发者都必须完成更新后的问卷；未完成的应用将无法更新。

为何有效：分级不匹配违反 Guideline 2.3.6。Apple 会将问卷答案与观察到的应用行为进行比对。最常见的漏报项是 UGC 和网页访问。

---

8. 缺少演示凭据

耗时：3-5 天（被拒 + 创建凭据 + 等待重新提交审核）

症状：因 Guideline 2.1 被拒。由于应用要求登录且未提供测试账户，审核人员无法测试应用。

❌ 错误做法：应用要求登录，但审核备注中没有演示账户

App Review Information:
  Notes: (empty)
  Demo Account: (empty)
  Demo Password: (empty)
→ Reviewer sees login screen, can't proceed, rejects

✅ 正确做法：提供可用的演示凭据和清晰的说明

App Review Information:
  Demo Account: [email protected]
  Demo Password: AppReview2025!
  Notes: "Log in with the demo account above.
         The account has sample data pre-loaded.
         To test [feature X], navigate to Tab 2 > Settings.
         If 2FA is required, use code: 123456"

Requirements:
- Account must not expire during review (1-2 weeks minimum)
- Account must have representative data
- Include any special setup steps
- If hardware required, explain workarounds
- If location-specific, provide test coordinates

为何有效：审核人员无法测试他们无法访问的内容。他们不会自行创建账户。如果应用要求任何形式的身份验证，就必须提供演示凭据。这是带有登录流程的应用最常见的拒审原因之一。

---

决策树

Is my app ready to submit?
│
├─ Does it crash on a real device?
│  ├─ YES → STOP. Fix crashes first (Guideline 2.1)
│  └─ NO → Continue
│
├─ Privacy manifest (PrivacyInfo.xcprivacy) present?
│  ├─ NO → Add privacy manifest with Required Reason APIs
│  └─ YES → Continue
│
├─ Privacy policy URL set in App Store Connect?
│  ├─ NO → Add privacy policy URL in ASC
│  └─ YES → Is it also accessible in-app?
│     ├─ NO → Add in-app privacy policy link
│     └─ YES → Continue
│
├─ All screenshots final and matching current app?
│  ├─ NO → Update screenshots for all required device sizes
│  └─ YES → Continue
│
├─ Does app create user accounts?
│  ├─ YES → Account deletion implemented and discoverable?
│  │  ├─ NO → Implement account deletion flow
│  │  └─ YES → Continue
│  └─ NO → Continue
│
├─ Does app offer third-party login (Google, Facebook, etc.)?
│  ├─ YES → Sign in with Apple offered?
│  │  ├─ NO → Add SIWA (unless exemption applies)
│  │  └─ YES → Continue
│  └─ NO → Continue
│
├─ Does app have in-app purchases or subscriptions?
│  ├─ YES → IAP items submitted for review in ASC?
│  │  ├─ NO → Submit IAP for review (can be reviewed separately)
│  │  └─ YES → Restore Purchases button implemented?
│  │     ├─ NO → Add Restore Purchases functionality
│  │     └─ YES → Continue
│  └─ NO → Continue
│
├─ Does app use encryption beyond standard HTTPS?
│  ├─ YES → Export compliance documentation uploaded?
│  │  ├─ NO → Add ITSAppUsesNonExemptEncryption to Info.plist
│  │  │       and upload compliance documentation
│  │  └─ YES → Continue
│  └─ NO → Set ITSAppUsesNonExemptEncryption = NO in Info.plist
│
├─ Distributing in EU?
│  ├─ YES → DSA trader status verified in ASC?
│  │  ├─ NO → Complete trader verification in ASC
│  │  └─ YES → Continue
│  └─ NO → Continue
│
├─ Does app require login to function?
│  ├─ YES → Demo credentials in App Review notes?
│  │  ├─ NO → Add working demo account + password + instructions
│  │  └─ YES → Continue
│  └─ NO → Continue
│
├─ Age rating questionnaire completed honestly?
│  ├─ NO → Complete updated questionnaire (new 13+/16+/18+ ratings)
│  └─ YES → Continue
│
├─ Any placeholder content remaining?
│  ├─ YES → Replace all placeholders with final content
│  └─ NO → Continue
│
└─ All checks passed → READY TO SUBMIT

---

强制性提交前检查清单

每次提交前都要完整执行此检查清单。逐项检查，不要只检查你认为适用的项目。

1. 构建配置

• 使用当前要求的 SDK 构建（截至 2025 年为 iOS 18 SDK / Xcode 16；自 2026 年 4 月 28 日起要求 iOS 26 SDK / Xcode 26）
• 在 Info.plist 中设置 ITSAppUsesNonExemptEncryption（如果仅使用 HTTPS，则设为 NO）
• 在装有最新正式版 iOS 的实体设备上测试应用
• 应用可在仅支持 IPv6 的网络上运行（Apple 审核网络采用 IPv6）
• 未使用私有/未公开 API
• 未引用预发布版/beta 操作系统功能，除非目标系统就是该操作系统
• 最低部署目标合理（未设置得过高）
• 已测试发布版本（不只是 Debug 配置）

2. 隐私

• 应用目标中包含 PrivacyInfo.xcprivacy 文件
• 所有 Required Reason API 均已使用获批的原因代码声明
• 每个第三方 SDK 都包含自己的隐私清单
• 已在 App Store Connect 中设置隐私政策 URL
• 可在应用内访问隐私政策（设置/关于页面）
• 隐私政策内容与实际数据收集做法一致
• 已提供所有 NS*UsageDescription 用途说明字符串（相机、位置等）
• 用途说明字符串解释了对用户的益处（而不只是“我们需要访问权限”）
• 如跟踪用户，已实施 App Tracking Transparency（ATT）
• 已在 ASC 中填写隐私营养标签，并确保其与清单一致

3. 元数据

• 应用名称（最多 30 个字符，不堆砌关键词）
• 副标题（最多 30 个字符）
• 描述（准确，不含误导性声明）
• 关键词（最多 100 个字符，以逗号分隔）
• 已设置类别和次要类别
• 已提供所有要求的设备尺寸截图（iPhone：6.9"、6.7"、6.5"、5.5"；通用应用的 iPad：13"）
• 截图展示的是当前应用界面（并非过时内容）
• App Preview 视频为最新版本（如有使用）
• 支持 URL 有效且可访问
• 营销 URL 有效（如已设置）
• 版权字符串为当年
• 版本号和构建号已递增
• 已撰写“更新内容”（适用于更新）

4. 账户与身份验证

• 已实现账户删除流程（如果支持创建账户）
• 账户删除是真正删除（而不只是停用）
• 删除账户时撤销 SIWA 令牌（如果使用 SIWA）
• 提供“使用 Apple 登录”（如果提供任何第三方登录方式）
• 删除账户时妥善处理有效订阅
• “恢复购买”按钮可正常使用（如果支持 IAP）
• IAP 项目已提交至 ASC 审核（如果是新增或有更改）
• 购买前清楚告知订阅条款

5. App 审核信息

• 已提供联系信息（姓名、电话、电子邮箱）
• 已提供演示账户用户名（如果需要登录）
• 已提供演示账户密码（如果需要登录）
• 演示账户在审核期间（1-2 周）不会过期
• 演示账户包含具有代表性的示例数据
• 已提供依赖硬件功能的特殊说明
• 备注中说明任何不明显的功能或流程
• 如果 App 使用定位功能，请提供测试坐标

6. 内容完整性

• 没有占位文本（lorem ipsum、TODO、“即将推出”）
• 没有失效链接或无法继续操作的界面
• 所有图片均为正式素材（没有图库水印）
• App 图标符合规范（1024x1024、无 Alpha 通道、无圆角）
• 所有标签页和屏幕都有可用内容
• 错误状态和空状态都有恰当的提示信息
• 引导/教程流程完整且准确
• 所有深层链接和通用链接都能正确跳转

7. 区域与合规

• 已核实欧盟 DSA 商家身份（如果在欧盟发行）
• 已完成更新后的年龄分级问卷（13+/16+/18+）
• 年龄分级符合实际内容（已申报 UGC、暴力内容和网络访问）
• 已上传出口合规文档（如果使用非豁免加密技术）
• 内容符合每个发行地区的当地法律
• 符合 GDPR（如果在欧盟发行）

8. 2025-2026 年新增要求

• 已完成更新后的年龄分级问卷（自 2026 年 1 月 31 日起为必填项）
• 已申报无障碍功能标签（新提交内容将逐步要求提供）
• 外部 AI 服务同意弹窗（如果 App 会向外部 AI 发送个人数据）
• 符合 SDK 最低版本要求（当前为 Xcode 16/iOS 18 SDK；自 2026 年 4 月 28 日起为 Xcode 26/iOS 26 SDK）

---

时间压力情境

情境 1：“今天下班前发布”

背景：PM 表示，App 必须今天提交，以配合下周的营销发布。

压力：截止期限 + 高管关注

自我说服的陷阱：

• “通过审核后再修复隐私政策”
• “占位内容只出现在一个屏幕上，他们不会注意到”
• “下次更新再添加账户删除功能”
• “内部测试通过了，不需要在设备上测试”

必须执行：运行完整的提交前检查清单。检查每一项。遗漏项目会导致审核被拒，使进度延误 3-7 天以上，远比检查清单所需的 30 分钟更糟。

为了省下 30 分钟而跳过检查清单，一旦导致审核被拒，就会损失 3-7 天。

沟通模板：“提交前检查发现了 [N] 个会导致审核被拒的问题。修复需要 [X hours]。不修复就提交一定会被拒，至少会耽误 3-7 天。让我现在修复这些问题——这是最快的上线途径。”

场景 2：“第三次被拒，想办法让它通过就行”

背景：应用因不同问题被拒了 3 次。开发者感到沮丧，想走捷径或与 Apple 争辩。

压力：沮丧情绪 + 沉没成本 + 想申诉而不是修复问题

自我说服的陷阱：

• “他们一直在找新问题——这不公平”
• “这次我要申诉，这不合理”
• “我把那个屏幕藏起来，不让审核人员看到”

必须执行：阅读每条拒绝消息的完整内容。从头开始执行完整的提交前检查清单。审核人员常会在后续审核中发现新问题，因为每轮都会深入检查——他们会探索之前没到达的屏幕、测试之前跳过的流程，并以更严格的态度进行审核。

每次被拒都说明提交前流程存在漏洞。不要与反馈对抗——应当吸收反馈，并有条理地弥补漏洞。

沟通模板：“多次被拒说明我们的流程存在系统性漏洞，而不是运气不好。我正在执行完整的提交前检查清单——这需要 30 分钟，但能避免陷入 3-7 天的循环：只修复部分问题，随后又被拒。”

---

场景 3：“这只是一个修复 Bug 的更新”

背景：只是修复了一个单行代码的 Bug。开发者以为应用已经获批，这次更新也会顺利通过。

压力：自满 + 之前获批带来的虚假信心

自我说服的陷阱：

• “上次使用相同的元数据也获批了”
• “我只改了一个文件，他们不需要重新审核所有内容”
• “他们不会重新检查隐私相关内容，因为这些没有变化”

必须执行：更新会依据当前指南进行审核。不同版本之间的要求可能会变化。隐私清单曾在审核周期中途成为强制要求。年龄分级问卷也进行了全面调整。SDK 最低版本要求每年都会提高。即使只是修复 Bug 的更新，也可能因前一版本获批时尚不存在的问题而被拒。

每次都要执行提交前检查清单。上次审核应用时尚不存在的要求，现在可能已开始执行。

沟通模板：“即使只是修复 Bug，App Review 也会依据当前指南审核，而不是依据我们上次获批时的指南。隐私清单要求和年龄分级问卷调整都是在审核周期中途推出的。现在花 30 分钟进行提交前检查，可以避免意外被拒。”

---

截图要求

截图必须与当前应用界面一致。所需尺寸、规格和规则请参见 app-store-ref 第 1 部分。

---

处理拒绝

阅读拒绝消息

每条拒绝消息都包含：

1. 指南编号 — 违反的具体条款
2. 说明 — 审核人员发现的问题
3. 截图/录屏 — 可视化证据（如适用）
4. 建议 — 有时会附上修复建议

回复策略

1. Read the FULL rejection message (every word)
2. Identify ALL guidelines cited (may be multiple)
3. Fix EVERY cited issue (not just the first one)
4. Run the complete pre-flight checklist
5. In your resubmission notes, explain what you fixed
6. Do NOT argue or explain why you think the rejection is wrong

何时申诉

以下情况适合申诉：

• 你认为审核人员误解了应用的功能
• 你的应用显然符合所引用的指南
• 你有证据支持自己的立场

以下情况不适合申诉：

• 你不同意指南本身
• 拒绝在技术上是正确的，但你觉得不公平
• 你想拖延修复问题

申诉流程

App Store Connect → Resolution Center → Reply
- Explain clearly why you believe the rejection is incorrect
- Provide specific evidence (screenshots, documentation)
- Remain professional and factual
- Apple's App Review Board will re-review
- One appeal per rejection
- Must respond to all information requests BEFORE appealing

加急审核

有两种符合条件的情况：

1. 关键 Bug 修复 — 提供在当前线上版本中复现 Bug 的步骤
2. 与活动相关的应用 — 提供活动名称、日期，以及你与该活动的关联

沟通选项（常被忽略）

• “与 App Review 会面”会议 — Apple 会定期提供 30 分钟的预约时段；请访问 developer.apple.com/events 查看是否有空档（并非随时开放）
• Bug 修复的灵活处理 — Apple 有时可能会批准 Bug 修复提交，同时附上说明性备注，指出应在下次更新中处理的其他非法律/安全问题，而不是阻止发布。这并非保证会发生，但实际中确有此类情况。
• App Store Connect 移动应用，可随时跟踪状态

元数据被拒与二进制文件被拒

类型	含义	处理方式
元数据被拒	截图、描述或 ASC 字段需要修正	在 ASC 中修正后重新提交（无需新建构建版本）
二进制文件被拒	代码／应用问题需要修正	修正代码，创建新归档并上传新构建版本

---

应用内购买审核

应用内购买项目需要单独审核。缺失或故障的应用内购买是《指南》3.1.1 下最常见的拒绝原因之一。

应用内购买提交检查清单

• 已在 ASC 中创建所有应用内购买产品，并填写完整元数据
• 每个产品都已上传应用内购买审核截图（展示用户购买时看到的内容，仅供审核使用，不会显示在 App Store 上）
• 已将应用内购买产品关联到此版本（仅首次提交：App 版本页面 → In-App Purchases 部分 → Select → 勾选每个产品）。首次获批后，后续应用内购买项目可单独提交。
• 已提交应用内购买产品以供审核
• 恢复购买按钮清晰可见且可正常使用
• 在确认购买前显示订阅条款（价格、周期、自动续订）
• 购买页面上显示使用条款和隐私政策链接（《DPLA》附表 2 要求，并由《指南》3.1.2(c) 引用）。SubscriptionStoreView 会自动从 ASC 元数据中处理这些内容；如果使用自定义付费墙界面，则需手动添加链接。
• 清楚说明免费试用条款
• 显示的价格与 ASC 配置一致
• 不含外部购买链接（《指南》3.1.1），除非符合 entitlement 的资格要求
• 已在沙盒环境中完成 StoreKit 测试

常见的应用内购买拒绝情形

❌ "Buy Premium" button that does nothing → Guideline 3.1.1
❌ No Restore Purchases option → Guideline 3.1.1
❌ Subscription auto-renews without clear disclosure → Guideline 3.1.2
❌ Free trial duration not shown before purchase → Guideline 3.1.2
❌ External purchase link without entitlement → Guideline 3.1.1
❌ IAP products not attached to submission version → Guideline 2.1 (reviewer can't see them)
❌ No review screenshot on IAP product → Guideline 2.1 (reviewer can't verify purchase UI)
❌ Terms of Use / Privacy Policy missing from paywall → DPLA Schedule 2 (use SubscriptionStoreView to avoid)

---

常见拒绝原因速查

指南	问题	预防措施
2.1	崩溃、功能故障、内容不完整	在设备上测试，审核内容
2.1	审核人员看不到应用内购买	将应用内购买关联到版本（在 ASC 中勾选），上传审核截图
2.3	元数据不准确、截图有误	审核截图，检查元数据
2.3.6	年龄分级不正确	如实填写问卷，申报 UGC
3.1.1	应用内购买问题、缺少恢复购买功能	测试所有应用内购买流程，添加恢复功能
4.0	设计问题：界面不佳、不符合标准的模式	遵循 HIG，在所有尺寸下进行测试
4.8	缺少通过 Apple 登录	添加 SIWA，并支持任意第三方登录
5.1.1(i)	缺少隐私政策／内容不充分	在 ASC 和应用内均提供具体内容
5.1.1(v)	无法删除账户	在应用内提供删除功能，而不只是停用
5.1.2	缺少 Required Reason API	完成隐私清单

---

App Store Connect 提交流程

有关 ASC 上传流程和构建版本处理详情，请参阅 app-store-ref 第 9 部分。

---

加密出口合规

大多数应用需要设置 ITSAppUsesNonExemptEncryption = false。完整决策树请参阅 app-store-ref 第 5 部分。

---

无障碍营养标签（2025 年新增）

新提交的应用将逐步需要提供无障碍营养标签。完整标签列表和申报规则请参阅 app-store-ref 第 10 部分。申报前请运行 axiom-accessibility-diag。

---

首次提交应用的开发者检查清单

对于首次提交应用的开发者，以下是一些经常遗漏的额外事项。如果需要从头创建隐私政策，请使用隐私政策生成器（有许多免费选项），并根据应用实际的数据处理方式进行定制——通用模板会被拒绝。

Apple Developer Program

• 已加入 Apple Developer Program（每年 $99）
• 已接受最新的 Apple Developer Program 许可协议
• 已在 ASC 中填写税务和银行信息（适用于付费应用／应用内购买）
• 已创建分发证书
• 已使用正确的 Bundle ID 注册 App ID
• 已为 App Store 分发创建 Provisioning Profile

App Store Connect 设置

• 在 ASC 中创建新的 App 记录
• Bundle ID 与 Xcode 项目完全一致
• 设置主要语言
• 声明内容权利（原创内容或已获授权）
• 配置定价和可用性
• 选择发布地区（全球或特定国家/地区）

首次操作常见错误

错误	结果	解决方法
Xcode 和 ASC 中的 Bundle ID 不一致	上传被拒绝	确保完全一致，包括大小写
分发证书已过期或缺失	归档无法上传	在 Developer Portal 中创建新证书
未接受许可协议	上传被阻止	在 developer.apple.com 上接受协议
税务表格未填写完整	付费 App 无法发布	在 ASC → Agreements, Tax, and Banking 中完成填写
在 Xcode 中选择了错误的团队	签名错误	在 Signing & Capabilities 中选择正确的团队

---

实际影响

之前：开发者未使用检查清单便提交 → 因缺少隐私清单被拒（3 天）→ 修复后重新提交 → 因缺少 SIWA 被拒（5 天）→ 修复后重新提交 → 因占位内容被拒（3 天）→ 可避免的问题白白耗费 11 天

之后：开发者进行 30 分钟的提交前检查 → 发现全部三个问题 → 用 4 小时修复 → 首次提交即获批准

关键启示：检查清单需要 30 分钟。每轮拒绝流程需要 3-7 天。账很好算。

---

资源

WWDC：2022-10166、2025-328、2025-224、2025-241

文档：/app-store/review/guidelines、/app-store/submitting、/app-store/app-privacy-details、/support/offering-account-deletion-in-your-app、/documentation/security/complying-with-encryption-export-regulations

技能：axiom-privacy-ux、axiom-storekit-ref、axiom-accessibility-diag、axiom-testflight-triage、axiom-app-store-connect-ref