App Store Submission

App Store 提交

Overview

概述

Systematic pre-flight checklist that catches 90% of App Store rejection causes before submission. Core principle: Ship once, ship right. Over 40% of App Store rejections cite Guideline 2.1 (App Completeness) — crashes, placeholders, broken links. Another 30% are metadata and privacy issues. A disciplined pre-flight process eliminates these preventable rejections.

Key insight: Apple rejected nearly 1.93 million submissions in 2024. Most rejections are not policy disagreements — they are checklist failures. A 30-minute pre-flight saves 3-7 days of rejection-fix-resubmit cycles.

系统化的预提交检查清单可在提交前排查90%的App Store拒审原因。核心原则：一次提交，一次通过。超过40%的App Store拒审原因指向准则2.1（应用完整性）——崩溃、占位符、链接失效。另有30%源于元数据和隐私问题。规范的预提交流程可消除这些可避免的拒审情况。

关键数据：2024年苹果拒审了近193万次提交。大多数拒审并非政策分歧，而是未完成检查清单。30分钟的预提交检查可节省3-7天的“拒审-修复-重新提交”周期。

When to Use This Skill

何时使用该技能

✅ Use this skill when:

Preparing to submit an app or update to the App Store
Submitting your first app as a new developer
Responding to an App Review rejection
Running a pre-submission audit before TestFlight or production
Updating an existing app after a long gap (new requirements may apply)
Wondering "is my app ready to submit?"

❌ Do NOT use this skill for:

Code signing and provisioning profiles (use build-debugging)
CI/CD pipeline setup
Performance optimization (use ios-performance)
UI testing automation (use ui-testing)
In-app purchase implementation (use storekit-ref)
Privacy manifest details (use privacy-ux for deep implementation)

✅ 在以下场景使用：

准备将应用或更新版本提交至App Store时
新开发者首次提交应用时
针对App审核拒审结果进行响应时
在TestFlight或正式发布前执行预提交审计时
长时间未更新后对现有应用进行更新时（可能有新要求）
不确定“我的应用是否已准备好提交？”时

❌ 请勿在以下场景使用：

代码签名和配置文件相关操作（请使用构建调试技能）
CI/CD流水线搭建
性能优化（请使用ios-performance技能）
UI测试自动化（请使用ui-testing技能）
内购功能实现（请使用storekit-ref技能）
隐私清单细节实现（请使用privacy-ux技能进行深度实现）

Example Prompts

示例提问

Real questions developers ask that this skill answers:

开发者常问的、该技能可解答的问题：

1. "Is my app ready to submit to the App Store?"

1. “我的应用是否已准备好提交至App Store？”

The skill provides a complete pre-flight checklist covering build, privacy, metadata, accounts, review info, content, and regional requirements

该技能会提供完整的预提交检查清单，涵盖构建、隐私、元数据、账号、审核信息、内容及区域要求

2. "What do I need before submitting my first iOS app?"

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

The skill walks through every requirement from scratch — privacy manifest, metadata fields, screenshots, demo credentials, age rating

该技能会从零开始梳理所有要求——隐私清单、元数据字段、截图、演示账号、年龄分级

3. "I keep getting rejected, what am I missing?"

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

The skill provides anti-patterns with specific rejection causes and the decision tree to identify gaps

该技能会提供反模式案例，包含具体拒审原因及用于排查漏洞的决策树

4. "What's the pre-submission checklist for App Store?"

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

The skill provides a categorized mandatory checklist with every item that triggers rejection if missing

该技能会提供分类后的强制检查清单，列出所有遗漏会导致拒审的项

5. "Do I need a privacy manifest?"

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

Yes. Since May 2024, missing privacy manifests cause automatic rejection. The skill explains when and how.

需要。自2024年5月起，缺失隐私清单会导致自动拒审。该技能会解释何时及如何配置隐私清单。

6. "My app update was rejected for metadata issues"

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

The skill covers metadata completeness requirements and the common gaps that trigger Guideline 2.3 rejections

该技能会涵盖元数据完整性要求，以及触发准则2.3拒审的常见漏洞

Anti-Patterns

反模式案例

1. Submitting without device testing

1. 未在真机上测试就提交

Time cost: 3-7 days (rejection + fix + resubmit wait)

Symptom: Rejection for Guideline 2.1 — App Completeness. Crashes, broken flows, or missing functionality discovered by App Review.

❌ BAD: Test only in Simulator, submit when build succeeds

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

✅ GOOD: Test on physical device with latest shipping OS, exercise all user flows

bash

undefined

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

症状：因准则2.1（应用完整性）被拒。App审核人员发现应用崩溃、流程失效或功能缺失。

❌ 错误做法：仅在模拟器中测试，构建成功就提交

“在模拟器里能运行，提交吧”
→ 拒审原因：iPhone 15 Pro上启动崩溃（内存限制）
→ 延误3-7天

✅ 正确做法：在搭载最新正式版系统的真机上测试，覆盖所有用户流程

bash

undefined

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

- 边缘场景：无网络、低存储、中断事件


**Why it works**: Simulator hides real-device constraints — memory limits, cellular networking behavior, hardware-specific APIs, thermal throttling. App Review tests on physical devices.

---


**原理**：模拟器会隐藏真机的限制——内存上限、蜂窝网络行为、硬件专属API、热节流。App审核人员会在真机上进行测试。

---

2. Missing or inadequate privacy policy

2. 缺失或不规范的隐私政策

Time cost: 2-5 days (rejection + policy creation + resubmit)

Symptom: Rejection for Guideline 5.1.1(i) — Data Collection and Storage. Privacy policy missing, inaccessible, or inconsistent with actual data practices.

❌ BAD: No privacy policy URL, or a generic template that doesn't match actual data collection

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

✅ GOOD: Privacy policy accessible in two places, specific to your app's data practices

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

Three-way consistency: Apple compares (a) your app's actual behavior, (b) your privacy policy content, and (c) your Privacy Nutrition Labels in ASC. All three must agree. If any of these three disagree, you get a 5.1.1 rejection. Check each SDK's documentation for its privacy manifest and data collection disclosure — your app's total data collection is your code PLUS all SDK data collection.

Why it works: Guideline 5.1.1(i) requires privacy policy accessible BOTH in ASC metadata AND within the app. The policy must specifically describe your app's data practices, not a generic template.

时间成本：2-5天（拒审+创建政策+重新提交）

症状：因准则5.1.1(i)（数据收集与存储）被拒。隐私政策缺失、无法访问，或与实际数据处理行为不一致。

❌ 错误做法：无隐私政策URL，或使用与实际数据收集不符的通用模板

隐私政策URL：（空）
— 或 —
隐私政策：“我们尊重您的隐私”（通用模板，无具体内容）

✅ 正确做法：在两处提供可访问的隐私政策，且内容与应用实际数据处理行为匹配

1. App Store Connect → 应用信息 → 隐私政策URL
2. 应用内 → 设置/关于界面 → 隐私政策链接
3. 政策内容需包含：
   - 所有收集的数据类型
   - 每种数据类型的用途
   - 第三方共享情况（对象及原因）
   - 数据保留期限
   - 如何申请删除数据

三方一致性要求：苹果会对比(a)应用实际行为、(b)隐私政策内容、(c) ASC中的隐私营养标签。三者必须一致。若有任何不一致，就会触发5.1.1拒审。请查阅每个SDK的文档获取其隐私清单和数据收集披露信息——应用的总数据收集量包含自有代码及所有SDK的数据收集。

原理：准则5.1.1(i)要求隐私政策需同时在ASC元数据和应用内可访问。政策内容必须具体描述应用的数据处理行为，而非通用模板。

3. Placeholder content left in build

3. 构建包中遗留占位符内容

Time cost: 3-5 days (rejection + content replacement + resubmit)

Symptom: Rejection for Guideline 2.1 — App Completeness. Reviewers find placeholder text, empty screens, or TODO artifacts.

❌ BAD: Ship with development artifacts visible to users

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

✅ GOOD: Every screen has final content and production assets

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)

Why it works: App Review tests every screen and tab, including states you might consider edge cases. They open every menu, tap every button, and switch every tab.

时间成本：3-5天（拒审+替换内容+重新提交）

症状：因准则2.1（应用完整性）被拒。审核人员发现占位符文本、空界面或TODO标记。

❌ 错误做法：发布时保留对用户可见的开发标记

- 引导页中的“Lorem ipsum”文本
- 显示“即将推出”的空标签页
- 点击后弹出“尚未实现”提示的按钮
- 默认应用图标（白色网格）

✅ 正确做法：所有界面均使用最终内容和生产资源

预提交内容审计：
- [ ] 所有界面使用真实内容（无Lorem ipsum）
- [ ] 所有图片均为最终生产资源
- [ ] 无“即将推出”或“建设中”界面
- [ ] 所有按钮执行预期操作
- [ ] 无数据/错误状态有恰当提示信息
- [ ] 应用图标为符合规格的最终版本（1024x1024，无透明通道）

原理：App审核人员会测试每个界面和标签页，包括你可能认为是边缘场景的状态。他们会打开每个菜单、点击每个按钮、切换每个标签页。

4. Ignoring privacy manifest

4. 忽略隐私清单

Time cost: 1-3 days (automatic rejection + manifest creation + resubmit)

Symptom: Automatic rejection before human review. Missing

PrivacyInfo.xcprivacy

or undeclared Required Reason APIs.

❌ BAD: No privacy manifest, or missing Required Reason API declarations

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

✅ GOOD: Privacy manifest present with all Required Reason APIs declared

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)

Common Required Reason APIs that need declaration:

```
UserDefaults
```
→ Reason
```
CA92.1
```
File timestamp APIs → Reason
```
C617.1
```
Disk space APIs → Reason
```
E174.1
```
System boot time → Reason
```
35F9.1
```

Why it works: Since May 2024, this is an automated gate. No human reviewer involved — the build processing system rejects submissions missing required privacy declarations.

时间成本：1-3天（自动拒审+创建清单+重新提交）

症状：人工审核前自动被拒。缺失

PrivacyInfo.xcprivacy

或未声明必填理由API。

❌ 错误做法：无隐私清单，或缺失必填理由API声明

项目中无PrivacyInfo.xcprivacy
— 或 —
使用UserDefaults、文件时间戳、磁盘空间API
但未声明获批理由

✅ 正确做法：存在隐私清单，且已声明所有必填理由API

项目必须包含：
├── PrivacyInfo.xcprivacy
│   ├── NSPrivacyTracking (true/false)
│   ├── NSPrivacyTrackingDomains (若开启追踪)
│   ├── NSPrivacyCollectedDataTypes (所有数据类型)
│   └── NSPrivacyAccessedAPITypes (所有必填理由API)
│
└── 第三方SDK清单（每个SDK需包含自身清单）

需要声明的常见必填理由API：

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

原理：自2024年5月起，这是自动化审核门槛，无需人工审核——构建处理系统会拒审缺失必填隐私声明的提交。

5. Missing Sign in with Apple

5. 缺失Sign in with Apple选项

Time cost: 3-7 days (SIWA implementation + resubmit)

Symptom: Rejection for Guideline 4.8. App offers third-party login (Google, Facebook, email) but no Sign in with Apple option.

❌ BAD: Third-party login without SIWA

swift

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

✅ GOOD: SIWA offered as equivalent option alongside any third-party login

swift

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

Exceptions (SIWA not required):

Company-internal or employee-only apps
Education apps using existing school accounts
Government/tax/banking apps requiring government ID
Apps that are a client for a specific third-party service
Apps using only the company's own authentication system

Why it works: Guideline 4.8 requires SIWA as an option whenever ANY third-party or social login is offered. Apple enforces this strictly.

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

症状：因准则4.8被拒。应用提供第三方登录（Google、Facebook、邮箱）但未提供Sign in with Apple选项。

❌ 错误做法：仅提供第三方登录，无SIWA

swift

// 登录界面提供：
// - 使用Google登录
// - 使用Facebook登录
// - 邮箱/密码登录
// ← 缺失：使用Apple登录

✅ 正确做法：在提供任何第三方登录的同时，提供同等的SIWA选项

swift

// 登录界面提供：
// - 使用Apple登录 ← 若有其他登录方式则必填
// - 使用Google登录
// - 使用Facebook登录
// - 邮箱/密码登录

例外情况（无需SIWA）：

企业内部或仅员工使用的应用
使用现有学校账号的教育类应用
要求政府身份证明的政务/税务/银行类应用
特定第三方服务的客户端应用
仅使用企业自有认证系统的应用

原理：准则4.8要求，只要提供任何第三方或社交登录，就必须提供SIWA选项。苹果会严格执行该要求。

6. No account deletion flow

6. 无账号删除流程

Time cost: 5-10 days (implementation + testing + resubmit)

Symptom: Rejection for Guideline 5.1.1(v). App allows account creation but provides no way to delete the account.

❌ BAD: Account creation without deletion capability

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

✅ GOOD: Full account deletion flow accessible in-app

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)

swift

// 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

Why it works: Required since June 2022. Must be actual deletion (not deactivation), must be in-app (not just email/website), and must revoke SIWA tokens if used. Apple tests this flow specifically.

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

症状：因准则5.1.1(v)被拒。应用允许创建账号，但未提供账号删除方式。

❌ 错误做法：允许创建账号，但无删除能力

- 存在注册按钮
- 应用内无“删除账号”选项
- “联系客服删除”（不符合要求）
- “停用账号”（与删除不同）

✅ 正确做法：应用内提供可访问的完整账号删除流程

账号删除要求：
1. 在设置/个人资料中可找到（不隐藏）
2. 明确标注“删除账号”（而非“停用”）
3. 说明删除的影响（数据移除、时间线）
4. 向用户确认删除完成
5. 若使用Sign in with Apple → 撤销SIWA令牌
6. 若有活跃订阅 → 告知用户先取消订阅
7. 删除需在合理时间内完成（数天，而非数月）

swift

// 撤销Sign in with Apple令牌（必填）
let appleIDProvider = ASAuthorizationAppleIDProvider()
let request = appleIDProvider.createRequest()

// 用户确认删除后：
// 向苹果的撤销端点发送请求，携带用户令牌
// 然后在服务器端删除账号数据

原理：自2022年6月起为必填项。必须是实际删除（而非停用），必须在应用内完成（不能仅通过邮件/网页），若使用SIWA则必须撤销令牌。苹果会专门测试该流程。

7. Wrong age rating

7. 年龄分级错误

Time cost: 2-4 days (re-answer questionnaire + possible content changes + resubmit)

Symptom: Rejection for Guideline 2.3.6 — Inaccurate metadata. Age rating doesn't reflect actual app content or capabilities.

❌ BAD: Understate content to get lower rating

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

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

✅ GOOD: Answer age rating questionnaire accurately

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)

New age ratings (January 31, 2026): Apple expanded from 4+/9+/12+/17+ to 5 tiers (4+/9+/13+/16+/18+) with new capability declarations for messaging, UGC, advertising, and parental controls. All developers must complete the updated questionnaire or app updates will be blocked.

Why it works: Mismatched ratings violate Guideline 2.3.6. Apple compares your questionnaire answers against observed app behavior. UGC and web access are the most commonly missed declarations.

时间成本：2-4天（重新填写问卷+可能的内容修改+重新提交）

症状：因准则2.3.6（元数据不准确）被拒。年龄分级与应用实际内容或功能不符。

❌ 错误做法：为获得更低分级而隐瞒内容

应用包含用户生成内容（聊天、帖子）
但年龄分级问卷中选择“无UGC”

应用 gameplay 包含卡通暴力
但选择“无暴力”

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

如实申报：
- 用户生成内容（聊天、论坛、社交功能）
- 暴力内容（即使是卡通/奇幻类）
- 成熟主题
- 脏话/低俗幽默
- 赌博（模拟或真实）
- 恐怖/惊悚主题
- 医疗/治疗信息
- 无限制网页访问（可打开任意URL的WebView）

新年龄分级（2026年1月31日起）：苹果将从4+/9+/12+/17+扩展为5个等级（4+/9+/13+/16+/18+），新增消息、UGC、广告、家长控制的功能申报。所有开发者必须完成更新后的问卷，否则应用更新会被阻止。

原理：分级不符违反准则2.3.6。苹果会将你的问卷答案与应用实际行为进行对比。UGC和网页访问是最常被遗漏的申报项。

8. Missing demo credentials

8. 缺失演示账号

Time cost: 3-5 days (rejection + credential creation + resubmit wait)

Symptom: Rejection for Guideline 2.1. Reviewer unable to test app because login is required and no test account was provided.

❌ BAD: App requires login, but no demo account in review notes

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

✅ GOOD: Working demo credentials with clear instructions

App Review Information:
  Demo Account: demo@yourapp.com
  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

Why it works: Reviewers cannot test what they cannot access. They will not create their own account. If your app requires any form of authentication, demo credentials are mandatory. This is one of the most common rejection reasons for apps with login flows.

时间成本：3-5天（拒审+创建账号+重新提交等待）

症状：因准则2.1被拒。审核人员因需要登录但未提供测试账号而无法测试应用。

❌ 错误做法：应用需要登录，但审核备注中无演示账号

App审核信息：
  备注：（空）
  演示账号：（空）
  演示密码：（空）
→ 审核人员看到登录界面，无法继续，拒审

✅ 正确做法：提供可用的演示账号及清晰说明

App审核信息：
  演示账号：demo@yourapp.com
  演示密码：AppReview2025!
  备注：“使用上述演示账号登录。
         该账号已预加载示例数据。
         测试[功能X]请导航至标签页2 > 设置。
         若需两步验证，使用验证码：123456”

要求：
- 账号在审核期间（至少1-2周）不得过期
- 账号包含代表性数据
- 包含任何特殊设置步骤
- 若需硬件支持，说明替代方案
- 若有地域限制，提供测试坐标

原理：审核人员无法测试无法访问的内容。他们不会自行创建账号。若应用需要任何形式的认证，演示账号是必填项。这是带登录流程的应用最常见的拒审原因之一。

Decision Tree

决策树

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

我的应用是否已准备好提交？
│
├─ 在真机上会崩溃吗？
│  ├─ 是 → 停止。先修复崩溃（准则2.1）
│  └─ 否 → 继续
│
├─ 是否存在隐私清单（PrivacyInfo.xcprivacy）？
│  ├─ 否 → 添加包含必填理由API的隐私清单
│  └─ 是 → 继续
│
├─ App Store Connect中是否设置了隐私政策URL？
│  ├─ 否 → 在ASC中添加隐私政策URL
│  └─ 是 → 应用内是否也可访问？
│     ├─ 否 → 添加应用内隐私政策链接
│     └─ 是 → 继续
│
├─ 所有截图是否为最终版本且与当前应用匹配？
│  ├─ 否 → 更新所有所需设备尺寸的截图
│  └─ 是 → 继续
│
├─ 应用是否允许创建用户账号？
│  ├─ 是 → 是否已实现可找到的账号删除功能？
│  │  ├─ 否 → 实现账号删除流程
│  │  └─ 是 → 继续
│  └─ 否 → 继续
│
├─ 应用是否提供第三方登录（Google、Facebook等）？
│  ├─ 是 → 是否提供Sign in with Apple？
│  │  ├─ 否 → 添加SIWA（除非符合例外情况）
│  │  └─ 是 → 继续
│  └─ 否 → 继续
│
├─ 应用是否包含内购或订阅？
│  ├─ 是 → ASC中是否已提交内购项目供审核？
│  │  ├─ 否 → 提交内购项目供审核（可单独审核）
│  │  └─ 是 → 是否已实现恢复购买按钮？
│  │     ├─ 否 → 添加恢复购买功能
│  │     └─ 是 → 继续
│  └─ 否 → 继续
│
├─ 应用是否使用了标准HTTPS之外的加密？
│  ├─ 是 → 是否已上传出口合规文档？
│  │  ├─ 否 → 在Info.plist中添加ITSAppUsesNonExemptEncryption
│  │  │       并上传合规文档
│  │  └─ 是 → 继续
│  └─ 否 → 在Info.plist中设置ITSAppUsesNonExemptEncryption = NO
│
├─ 是否在欧盟地区分发？
│  ├─ 是 → ASC中是否已验证DSA商家身份？
│  │  ├─ 否 → 在ASC中完成商家身份验证
│  │  └─ 是 → 继续
│  └─ 否 → 继续
│
├─ 应用是否需要登录才能使用？
│  ├─ 是 → App审核备注中是否有演示账号？
│  │  ├─ 否 → 添加可用的演示账号+密码+说明
│  │  └─ 是 → 继续
│  └─ 否 → 继续
│
├─ 是否如实完成年龄分级问卷？
│  ├─ 否 → 完成更新后的问卷（新增13+/16+/18+分级）
│  └─ 是 → 继续
│
├─ 是否仍有占位符内容？
│  ├─ 是 → 将所有占位符替换为最终内容
│  └─ 否 → 继续
│
└─ 所有检查通过 → 可提交

Mandatory Pre-Flight Checklist

强制预提交检查清单

Run this entire checklist before every submission. Check every item, not just the ones you think apply.

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

1. Build Configuration

1. 构建配置

Built with current required SDK (iOS 18 SDK / Xcode 16 as of 2025; iOS 26 SDK / Xcode 26 required starting April 28, 2026)
```
ITSAppUsesNonExemptEncryption
```
set in Info.plist (
```
NO
```
if only HTTPS)
App tested on physical device with latest shipping iOS version
App works over IPv6-only network (Apple review network is IPv6)
No private/undocumented API usage
No references to pre-release/beta OS features unless targeting that OS
Minimum deployment target is reasonable (not unnecessarily high)
Release build tested (not just Debug configuration)

使用当前要求的SDK构建（2025年为iOS 18 SDK / Xcode 16；2026年4月28日起需iOS 26 SDK / Xcode 26）
Info.plist中已设置
```
ITSAppUsesNonExemptEncryption
```
（仅使用HTTPS则设为
```
NO
```
）
在搭载最新正式版iOS的真机上测试过应用
应用在仅IPv6网络下可正常工作（苹果审核网络为IPv6）
未使用私有/未公开API
未提及预发布/测试版OS功能（除非目标为该OS版本）
最低部署版本设置合理（无需过高）
测试过发布版本构建（而非仅Debug配置）

2. Privacy

2. 隐私合规

```
PrivacyInfo.xcprivacy
```
file present in app target
All Required Reason APIs declared with approved reason codes
Third-party SDKs each include their own privacy manifests
Privacy policy URL set in App Store Connect
Privacy policy accessible in-app (Settings/About screen)
Privacy policy content matches actual data collection practices
All
```
NS*UsageDescription
```
purpose strings present (Camera, Location, etc.)
Purpose strings explain user benefit (not just "we need access")
App Tracking Transparency implemented if tracking users (ATT)
Privacy Nutrition Labels completed in ASC matching manifest

应用目标中存在
```
PrivacyInfo.xcprivacy
```
文件
所有必填理由API已按获批理由代码声明
每个第三方SDK均包含自身隐私清单
App Store Connect中已设置隐私政策URL
应用内可访问隐私政策（设置/关于界面）
隐私政策内容与实际数据收集行为一致
所有
```
NS*UsageDescription
```
用途说明已存在（相机、位置等）
用途说明解释了对用户的益处（而非仅“我们需要权限”）
若追踪用户则已实现App Tracking Transparency（ATT）
ASC中已完成与隐私清单匹配的隐私营养标签

3. Metadata

3. 元数据

4. Account and Authentication

4. 账号与认证

Account deletion flow implemented (if account creation exists)
Account deletion is actual deletion (not just deactivation)
SIWA token revocation on account deletion (if SIWA used)
Sign in with Apple offered (if any third-party login exists)
Active subscriptions handled during account deletion
Restore Purchases button works (if IAP exists)
IAP items submitted for review in ASC (if new/changed)
Subscription terms clearly communicated before purchase

已实现账号删除流程（若允许创建账号）
账号删除为实际删除（而非仅停用）
账号删除时已撤销SIWA令牌（若使用SIWA）
若提供第三方登录则已提供Sign in with Apple
账号删除时已处理活跃订阅
恢复购买按钮可正常工作（若有内购）
ASC中已提交内购项目供审核（若有新增/修改）
订阅条款在购买前已清晰告知用户

5. App Review Information

5. App审核信息

Contact information (name, phone, email) provided
Demo account username provided (if login required)
Demo account password provided (if login required)
Demo account won't expire during review period (1-2 weeks)
Demo account has representative sample data
Special instructions for hardware-dependent features
Notes explain any non-obvious features or flows
If app uses location, provide test coordinates

已提供联系信息（姓名、电话、邮箱）
已提供演示账号用户名（若需要登录）
已提供演示账号密码（若需要登录）
演示账号在审核期间（1-2周）不会过期
演示账号包含代表性示例数据
已提供硬件相关功能的特殊说明
备注中解释了任何不明显的功能或流程
若应用使用位置服务，已提供测试坐标

6. Content Completeness

6. 内容完整性

No placeholder text (lorem ipsum, TODO, "Coming Soon")
No broken links or dead-end screens
All images are production assets (no stock watermarks)
App icon meets spec (1024x1024, no alpha channel, no rounded corners)
All tabs/screens have functional content
Error states and empty states have proper messaging
Onboarding/tutorial flows complete and accurate
All deep links and universal links resolve correctly

无占位符文本（Lorem ipsum、TODO、“即将推出”）
无失效链接或死胡同界面
所有图片均为生产资源（无素材水印）
应用图标符合规格（1024x1024，无透明通道，无圆角）
所有标签页/界面均有可用内容
错误状态和无数据状态有恰当提示信息
引导/教程流程完整且准确
所有深度链接和通用链接均可正确跳转

7. Regional and Compliance

7. 区域与合规

EU DSA trader status verified (if distributing in EU)
Age rating questionnaire completed with updated categories (13+/16+/18+)
Age rating reflects actual content (UGC, violence, web access declared)
Export compliance documentation uploaded (if non-exempt encryption)
Content complies with local laws for each distribution territory
GDPR compliance (if distributing in EU)

若在欧盟分发，已验证DSA商家身份
已使用更新后的分类完成年龄分级问卷（13+/16+/18+）
年龄分级反映实际内容（已申报UGC、暴力、网页访问）
若使用非豁免加密，已上传出口合规文档
内容符合每个分发地区的当地法律
符合GDPR要求（若在欧盟分发）

8. New for 2025-2026

8. 2025-2026年新增要求

Updated age rating questionnaire completed (deadline: January 31, 2026)
Accessibility Nutrition Labels declared (becoming required for new submissions)
External AI service consent modal (if app sends personal data to external AI)
SDK minimum version met (Xcode 16/iOS 18 SDK now; Xcode 26/iOS 26 SDK starting April 28, 2026)

已完成更新后的年龄分级问卷（截止日期：2026年1月31日）
已声明无障碍营养标签（即将成为新提交应用的必填项）
若应用向外部AI服务发送个人数据，已添加同意弹窗
符合SDK最低版本要求（现为Xcode 16/iOS 18 SDK；2026年4月28日起需Xcode 26/iOS 26 SDK）

Pressure Scenarios

压力场景应对

Scenario 1: "Ship by end of day"

场景1：“今天必须提交”

Setup: PM says the app must be submitted today for a marketing launch next week.

Pressure: Deadline + executive visibility

Rationalization traps:

"We'll fix the privacy policy after approval"
"The placeholder is only on one screen, they won't notice"
"We'll add account deletion in the next update"
"It passed internal testing, no need for device testing"

MANDATORY: Run the full pre-flight checklist. Every item. Missing items cause rejection, which costs 3-7 MORE days — far worse than the 30 minutes the checklist takes.

Skipping the checklist to save 30 minutes costs 3-7 days when it causes rejection.

Communication template: "The pre-flight check found [N] issues that will cause rejection. Fixing them takes [X hours]. Submitting without fixing guarantees rejection, which costs 3-7 days minimum. Let me fix these now — it's the fastest path to being live."

背景：产品经理要求今天提交应用，以配合下周的营销发布。

压力：截止期限+管理层关注

合理化陷阱：

“我们可以在获批后再修复隐私政策”
“只有一个界面有占位符，他们不会注意到”
“我们可以在下一个版本中添加账号删除功能”
“内部测试通过了，不需要真机测试”

强制要求：执行完整的预提交检查清单。每一项都要检查。遗漏项会导致拒审，这会额外花费3-7天——远超过检查清单所需的30分钟。

为节省30分钟而跳过检查清单，会因拒审浪费3-7天。

沟通模板：“预提交检查发现[N]个会导致拒审的问题，修复需要[X]小时。不修复就提交必然会被拒审，至少延误3-7天。我现在修复这些问题——这是最快上线的方式。”

Scenario 2: "Third rejection, just make it work"

场景2：“第三次被拒，赶紧搞定”

Setup: App rejected 3 times for different issues each time. Developer is frustrated and tempted to cut corners or argue with Apple.

Pressure: Frustration + sunk cost + temptation to appeal instead of fix

Rationalization traps:

"They keep finding new issues — they're being unfair"
"I'll appeal this one, it's unreasonable"
"I'll just hide that screen from reviewers"

MANDATORY: Read the FULL text of every rejection message. Run the complete pre-flight checklist from scratch. Reviewers often find new issues on subsequent reviews because they test deeper each pass — they explore screens they didn't reach before, test flows they skipped, and review with stricter attention.

Each rejection is a signal that the pre-submission process has gaps. Do not fight the feedback — absorb it and close the gaps systematically.

Communication template: "Multiple rejections mean we have systematic gaps, not bad luck. I'm running the complete pre-flight checklist — this takes 30 minutes but prevents the 3-7 day cycle of partial fixes followed by new rejections."

背景：应用已被拒3次，每次原因不同。开发者感到沮丧，想走捷径或与苹果争论。

压力：沮丧+沉没成本+想申诉而非修复的冲动

合理化陷阱：

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

强制要求：阅读完整的拒审消息。从头开始执行完整的预提交检查清单。审核人员在后续审核中通常会发现新问题，因为他们每次测试都会更深入——会探索之前未到达的界面、测试之前跳过的流程、更严格地审核。

每次拒审都表明预提交流程存在漏洞。不要抗拒反馈——接受并系统性地填补漏洞。

沟通模板：“多次拒审说明我们存在系统性漏洞，而非运气不好。我正在执行完整的预提交检查清单——这需要30分钟，但能避免‘部分修复后再次被拒’的3-7天循环。”

Scenario 3: "It's just a bug fix update"

场景3：“只是一个bug修复更新”

Setup: Simple one-line bug fix. Developer assumes the update will sail through because the app was already approved.

Pressure: Complacency + false confidence from prior approval

Rationalization traps:

"It was approved last time with the same metadata"
"I only changed one file, they don't need to re-review everything"
"They won't re-check the privacy stuff, it hasn't changed"

MANDATORY: Updates are reviewed against CURRENT guidelines. Requirements change between releases. Privacy manifests became mandatory mid-cycle. Age rating questionnaire was overhauled. SDK minimums increase annually. A bug fix update can be rejected for issues that didn't exist when the previous version was approved.

Run the pre-flight checklist every time. Requirements that didn't exist when your app was last reviewed may now be enforced.

Communication template: "Even for a bug fix, App Review applies current guidelines — not the ones from when we were last approved. The privacy manifest requirement and age rating overhaul both came mid-cycle. Running the 30-minute pre-flight now prevents a surprise rejection."

背景：仅修复了一行代码的bug。开发者认为应用之前已获批，这次更新会顺利通过。

压力：自满+之前获批带来的错误信心

合理化陷阱：

“上次获批时元数据和现在一样”
“我只改了一个文件，他们不需要重新审核所有内容”
“他们不会再检查隐私相关内容，没变化”

强制要求：更新版本会按照当前准则进行审核。要求会在版本迭代间变化。隐私清单是在周期中途成为必填项的。年龄分级问卷已全面更新。SDK最低要求每年都会提高。bug修复更新可能会因之前版本获批时不存在的要求而被拒。

每次提交都要执行预提交检查清单。上次获批后可能已新增了必须遵守的要求。

沟通模板：“即使是bug修复，App审核也会应用当前准则——而非上次获批时的准则。隐私清单要求和年龄分级 overhaul都是在周期中途推出的。现在花30分钟执行预提交检查，可避免意外拒审。”

Screenshot Requirements

截图要求

Screenshots are a top rejection cause under Guideline 2.3 (Accurate Metadata). Screenshots must match the current app UI.

截图是准则2.3（元数据准确）下的主要拒审原因之一。截图必须与当前应用UI匹配。

Required Device Sizes (iPhone)

iPhone所需设备尺寸

Display Size	Devices	Required?
6.9"	iPhone 16 Pro Max	Required for new apps
6.7"	iPhone 16 Plus, 15 Plus, 14 Plus	Required
6.5"	iPhone 11 Pro Max, XS Max	Optional (falls back to 6.7")
5.5"	iPhone 8 Plus, 7 Plus	Required for apps supporting older devices

屏幕尺寸	设备	是否必填
6.9"	iPhone 16 Pro Max	新应用必填
6.7"	iPhone 16 Plus、15 Plus、14 Plus	必填
6.5"	iPhone 11 Pro Max、XS Max	可选（ fallback至6.7"）
5.5"	iPhone 8 Plus、7 Plus	支持旧设备的应用必填

Required Device Sizes (iPad)

iPad所需设备尺寸

Display Size	Devices	Required?
13"	iPad Pro (M4)	Required if universal app
12.9"	iPad Pro (5th gen)	Optional (falls back to 13")
11"	iPad Air, iPad Pro 11"	Optional

屏幕尺寸	设备	是否必填
13"	iPad Pro (M4)	通用应用必填
12.9"	iPad Pro (5th gen)	可选（ fallback至13"）
11"	iPad Air、iPad Pro 11"	可选

Screenshot Rules

截图规则

DO:
- Show actual app UI (not mockups or renders)
- Include text that matches current app content
- Show the app running on the device (can include device frames)
- Update screenshots when UI changes significantly
- Use all available screenshot slots (up to 10) for better conversion

DON'T:
- Show UI from a different version of the app
- Include misleading features or content not in the app
- Use competitor names or logos
- Show pricing that doesn't match actual IAP prices
- Include iPhone status bar showing incorrect carrier/time

需要：
- 展示实际应用UI（而非原型或渲染图）
- 包含与当前应用内容匹配的文本
- 展示应用在设备上的运行状态（可包含设备边框）
- UI大幅变化时更新截图
- 使用所有可用截图位（最多10个）以提升转化率

禁止：
- 展示应用其他版本的UI
- 包含应用中不存在的误导性功能或内容
- 使用竞品名称或logo
- 展示与实际内购价格不符的定价
- 包含显示错误运营商/时间的iPhone状态栏

App Preview Videos

App预览视频

Maximum 30 seconds
Must show actual app functionality (not pre-rendered marketing)
Audio is muted by default on the App Store
Required sizes mirror screenshot requirements

最长30秒
必须展示实际应用功能（而非预渲染的营销内容）
App Store上默认静音
所需尺寸与截图要求一致

Handling Rejections

拒审处理

Reading the Rejection Message

阅读拒审消息

Every rejection includes:

Guideline number — Specific section violated
Description — What the reviewer found
Screenshots/recordings — Visual evidence (if applicable)
Suggestions — Sometimes included with fixes

每条拒审消息包含：

准则编号——违反的具体章节
描述——审核人员发现的问题
截图/录屏——视觉证据（若有）
建议——有时会包含修复建议

Response Strategy

响应策略

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

1. 阅读完整的拒审消息（每一个字）
2. 识别所有被引用的准则（可能多个）
3. 修复所有被引用的问题（而非仅第一个）
4. 执行完整的预提交检查清单
5. 在重新提交备注中说明你修复了哪些问题
6. 不要争论或解释你认为拒审不合理的原因

When to Appeal

何时申诉

Appeals are appropriate when:

You believe the reviewer misunderstood your app's functionality
Your app clearly complies with the cited guideline
You have evidence supporting your position

Appeals are NOT appropriate when:

You disagree with the guideline itself
The rejection is technically correct but feels unfair
You want to delay fixing the issue

以下情况适合申诉：

你认为审核人员误解了应用的功能
你的应用明显符合被引用的准则
你有支持你立场的证据

以下情况不适合申诉：

你不同意准则本身
拒审在技术上正确但你觉得不公平
你想推迟修复问题

Appeal Process

申诉流程

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

App Store Connect → Resolution Center → 回复
- 清晰说明你认为拒审错误的原因
- 提供具体证据（截图、文档）
- 保持专业和客观
- 苹果App审核委员会会重新审核

Metadata Rejected vs Binary Rejected

元数据拒审 vs 二进制拒审

Type	What it means	What to do
Metadata Rejected	Screenshots, description, or ASC fields need fixing	Fix in ASC, resubmit (no new build needed)
Binary Rejected	Code/app issue needs fixing	Fix code, create new archive, upload new build

类型	含义	处理方式
元数据拒审	截图、描述或ASC字段需要修复	在ASC中修复，重新提交（无需新构建）
二进制拒审	代码/应用存在问题需要修复	修复代码，创建新归档，上传新构建

In-App Purchase Review

内购审核

IAP items require separate review. Missing or broken IAP is a top rejection cause under Guideline 3.1.1.

内购项目需要单独审核。缺失或失效的内购是准则3.1.1下的主要拒审原因。

IAP Submission Checklist

内购提交检查清单

All IAP products created in ASC with screenshots
IAP products submitted for review (can be submitted independently)
Restore Purchases button visible and functional
Subscription terms displayed before purchase confirmation
Free trial terms clearly communicated
Pricing displayed matches ASC configuration
No external purchase links (Guideline 3.1.1) unless eligible for entitlement
StoreKit testing completed in sandbox environment

所有内购产品已在ASC中创建并添加截图
内购产品已提交供审核（可单独提交）
恢复购买按钮可见且可正常工作
购买确认前已显示订阅条款
免费试用条款已清晰告知
展示的定价与ASC配置一致
无外部购买链接（准则3.1.1），除非符合豁免资格
已在沙箱环境中完成StoreKit测试

Common IAP Rejection Patterns

常见内购拒审模式

❌ "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

❌ “购买高级版”按钮无响应 → 准则3.1.1
❌ 无恢复购买选项 → 准则3.1.1
❌ 订阅自动续费无清晰披露 → 准则3.1.2
❌ 购买前未显示免费试用时长 → 准则3.1.2
❌ 无豁免资格但存在外部购买链接 → 准则3.1.1

Common Rejection Reasons Quick Reference

常见拒审原因速查

Guideline	Issue	Prevention
2.1	Crashes, broken features, incomplete	Device testing, content audit
2.3	Inaccurate metadata, wrong screenshots	Screenshot audit, metadata review
2.3.6	Incorrect age rating	Honest questionnaire, declare UGC
3.1.1	IAP issues, missing Restore Purchases	Test all IAP flows, add restore
4.0	Design: poor UI, non-standard patterns	Follow HIG, test on all sizes
4.8	Missing Sign in with Apple	Add SIWA with any third-party login
5.1.1(i)	Privacy policy missing/inadequate	Both ASC and in-app, specific content
5.1.1(v)	No account deletion	In-app deletion, not just deactivation
5.1.2	Missing Required Reason APIs	Complete privacy manifest

准则	问题	预防措施
2.1	崩溃、功能失效、不完整	真机测试、内容审计
2.3	元数据不准确、截图错误	截图审计、元数据复查
2.3.6	年龄分级错误	如实填写问卷、申报UGC
3.1.1	内购问题、缺失恢复购买	测试所有内购流程、添加恢复购买功能
4.0	设计：UI差、非标准模式	遵循HIG、在所有尺寸设备上测试
4.8	缺失Sign in with Apple	提供第三方登录时添加SIWA
5.1.1(i)	隐私政策缺失/不规范	同时在ASC和应用内提供、内容具体
5.1.1(v)	无账号删除	应用内实现删除功能，而非仅停用
5.1.2	缺失必填理由API	完成隐私清单

App Store Connect Submission Workflow

App Store Connect提交流程

Step-by-step for a clean submission

顺利提交的分步指南

1. Create new version in ASC
2. Set version number and "What's New" text
3. Upload screenshots (all required sizes)
4. Complete App Review Information section
   - Contact info
   - Demo credentials (if login required)
   - Notes for reviewer
5. Verify Privacy Nutrition Labels
6. Verify age rating questionnaire
7. Upload build from Xcode (Product → Archive → Distribute)
8. Wait for build processing (5-30 minutes)
9. Select processed build in ASC
10. Submit for Review

1. 在ASC中创建新版本
2. 设置版本号和“新功能”文本
3. 上传截图（所有所需尺寸）
4. 完成App审核信息部分
   - 联系信息
   - 演示账号（若需要登录）
   - 给审核人员的备注
5. 验证隐私营养标签
6. 验证年龄分级问卷
7. 从Xcode上传构建（Product → Archive → Distribute）
8. 等待构建处理（5-30分钟）
9. 在ASC中选择已处理的构建
10. 提交审核

Build upload checklist

构建上传检查清单

bash

undefined

bash

undefined

Before archiving

归档前

xcodebuild -showBuildSettings -scheme YourApp | grep -E "PRODUCT_BUNDLE_IDENTIFIER|MARKETING_VERSION|CURRENT_PROJECT_VERSION"

Verify signing

验证签名

xcodebuild -scheme YourApp -showBuildSettings | grep "CODE_SIGN"

归档

xcodebuild archive -scheme YourApp
-archivePath ./build/YourApp.xcarchive

Or use Xcode: Product → Archive → Distribute → App Store Connect

或使用Xcode：Product → Archive → Distribute → App Store Connect

undefined

undefined

After submission

提交后

Review time: ~90% reviewed within 24 hours
Check status: ASC → My Apps → your app → App Store tab
If rejected: Read FULL rejection text, fix ALL cited issues, run pre-flight again
If "Metadata Rejected": Can fix metadata without new build upload
If "Binary Rejected": Need new build upload

审核时间：约90%的提交会在24小时内完成审核
查看状态：ASC → 我的应用 → 你的应用 → App Store标签页
若被拒：阅读完整拒审文本，修复所有被引用的问题，再次执行预提交检查
若为“元数据拒审”：无需上传新构建，可直接修复元数据
若为“二进制拒审”：需要上传新构建

Encryption Export Compliance

加密出口合规

Quick determination

快速判断

Most apps only use HTTPS (URLSession, Alamofire, etc.). This is standard encryption that's exempt from documentation requirements but still requires declaration.

xml

<!-- Info.plist — Add this to skip the compliance question on every upload -->
<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Set to

true

only if your app uses:

Custom encryption algorithms
Encryption beyond what the OS provides
Proprietary cryptographic protocols
Direct calls to OpenSSL or similar libraries

If

true

, you must upload export compliance documentation in ASC.

Note: Even with

ITSAppUsesNonExemptEncryption = false

, if you make HTTPS calls you must submit an annual self-classification report to the US Bureau of Industry and Security. Apple provides guidance on this in App Store Connect.

大多数应用仅使用HTTPS（URLSession、Alamofire等）。这是标准加密，无需提交文档，但仍需声明。

xml

<!-- Info.plist — 添加此项可跳过每次上传时的合规问题 -->
<key>ITSAppUsesNonExemptEncryption</key>
<false/>

仅在以下情况设为

true

：

使用自定义加密算法
使用OS提供之外的加密
使用专有加密协议
直接调用OpenSSL或类似库

若设为

true

，你必须在ASC中上传出口合规文档。

注意：即使

ITSAppUsesNonExemptEncryption = false

，若你进行HTTPS调用，仍需每年向美国工业和安全局提交自我分类报告。苹果会在App Store Connect中提供相关指导。

Accessibility Nutrition Labels (New 2025)

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

Declared per-device in App Store Connect. Initially optional but becoming required for new submissions and updates.

在App Store Connect中按设备声明。最初为可选，但即将成为新提交应用和更新的必填项。

Available Labels

可用标签

Label	What it means	How to verify
VoiceOver	All common tasks completable with VoiceOver	Test every screen with VoiceOver enabled
Voice Control	All common tasks completable with voice commands	Test navigation and input with Voice Control
Larger Text	UI adapts to Dynamic Type sizes up to AX5	Test with largest Accessibility text size
Dark Interface	Full dark mode support	Test every screen in dark mode
Sufficient Contrast	Text and controls meet WCAG AA contrast ratios	Audit with Accessibility Inspector
Differentiation Without Color	Information not conveyed by color alone	Check all status indicators, errors, states
Reduced Motion	Animations respect Reduce Motion setting	Enable Reduce Motion, verify all transitions

标签	含义	验证方式
VoiceOver	所有常见任务可通过VoiceOver完成	启用VoiceOver导航每个界面，完成核心流程
Voice Control	所有常见任务可通过语音命令完成	使用语音控制测试导航和输入
Larger Text	UI适配Dynamic Type至AX5尺寸	使用最大无障碍文本尺寸测试
Dark Interface	完整支持深色模式	在深色模式下测试每个界面
Sufficient Contrast	文本和控件符合WCAG AA对比度标准	使用无障碍检查器审计
Differentiation Without Color	信息不单独通过颜色传达	检查所有状态指示器、错误提示、状态
Reduced Motion	动画遵循Reduce Motion设置	启用Reduce Motion，验证所有过渡效果

Declaration Rules

声明规则

Declare per device (iPhone, iPad, Apple Watch separately)
Each declaration means users can complete ALL common tasks using that feature
Do not declare partial support — all-or-nothing per feature
Labels are saved as drafts first, published when ready
Can publish individual device declarations separately

按设备声明（iPhone、iPad、Apple Watch分别声明）
每项声明意味着用户可使用该功能完成所有常见任务
不要声明部分支持——每项功能要么完全支持，要么不支持
标签先保存为草稿，准备好后发布
可单独发布单个设备的声明

Before Declaring

声明前准备

Run an accessibility audit of your app:

1. Enable VoiceOver → Navigate every screen → Complete core flows
2. Enable Voice Control → Same test
3. Set text size to AX5 → Check all screens for truncation/overlap
4. Switch to Dark Mode → Check all screens for legibility
5. Run Accessibility Inspector → Check contrast ratios
6. Enable Reduce Motion → Verify animations are reduced/removed

See

axiom-accessibility-diag

for systematic auditing before declaring labels.

对应用进行无障碍审计：

1. 启用VoiceOver → 导航每个界面 → 完成核心流程
2. 启用Voice Control → 重复测试
3. 将文本尺寸设为AX5 → 检查所有界面是否有截断/重叠
4. 切换至深色模式 → 检查所有界面的可读性
5. 运行无障碍检查器 → 检查对比度
6. 启用Reduce Motion → 验证动画已减少/移除

声明标签前，可使用

axiom-accessibility-diag

进行系统化审计。

First-Time Developer Checklist

首次开发者检查清单

For developers submitting their first app, these are additional items often missed. If you need to create a privacy policy from scratch, use a privacy policy generator (many free options exist) and customize it to match your app's actual data practices — a generic template will be rejected.

针对首次提交应用的开发者，以下是常被遗漏的额外项。若你需要从零开始创建隐私政策，可使用隐私政策生成器（有很多免费选项），并根据应用实际数据处理行为进行自定义——通用模板会被拒审。

Apple Developer Program

Apple开发者计划

Enrolled in Apple Developer Program ($99/year)
Accepted latest Apple Developer Program License Agreement
Tax and banking information completed in ASC (for paid apps/IAP)
Distribution certificate created
App ID registered with correct bundle identifier
Provisioning profile created for App Store distribution

已加入Apple开发者计划（99美元/年）
已接受最新的Apple开发者计划许可协议
ASC中已完成税务和银行信息（针对付费应用/内购）
已创建分发证书
已注册与正确bundle identifier匹配的App ID
已创建用于App Store分发的配置文件

App Store Connect Setup

App Store Connect设置

New app record created in ASC
Bundle ID matches Xcode project exactly
Primary language set
Content rights declared (original content or licensed)
Pricing and availability configured
Territory selection (worldwide or specific countries)

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

Common First-Time Mistakes

首次开发者常见错误

Mistake	Result	Fix
Bundle ID mismatch between Xcode and ASC	Upload rejected	Match exactly, including case
Distribution cert expired/missing	Archive fails to upload	Create new cert in Developer Portal
License agreement not accepted	Upload blocked	Accept in developer.apple.com
Tax forms incomplete	Paid app not distributed	Complete in ASC → Agreements, Tax, and Banking
Wrong team selected in Xcode	Signing errors	Select correct team in Signing & Capabilities

错误	后果	修复方式
Xcode与ASC中的Bundle ID不匹配	上传被拒	完全匹配，包括大小写
分发证书过期/缺失	归档无法上传	在开发者门户中创建新证书
未接受许可协议	上传被阻止	在developer.apple.com中接受
税务表格未完成	付费应用无法分发	在ASC → 协议、税务和银行中完成
Xcode中选择了错误的团队	签名错误	在签名与功能中选择正确团队

Real-World Impact

实际效果

Before: Developer submits without checklist → rejected for missing privacy manifest (3 days) → fixes, resubmits → rejected for missing SIWA (5 days) → fixes, resubmits → rejected for placeholder content (3 days) → 11 days lost to preventable issues

After: Developer runs 30-minute pre-flight → catches all three issues → fixes in 4 hours → approved on first submission

Key insight: The checklist takes 30 minutes. Each rejection cycle takes 3-7 days. The math is simple.

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

之后：开发者执行30分钟预提交检查 → 发现所有三个问题 → 4小时内修复 → 首次提交即获批

关键结论：检查清单需要30分钟。每个拒审周期需要3-7天。利弊显而易见。

Related Skills

Resources

资源

WWDC: 2022-10166, 2025-328, 2025-224, 2025-241

Docs: /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

Skills: axiom-privacy-ux, axiom-storekit-ref, axiom-accessibility-diag, axiom-testflight-triage

Last Updated: 2026-02-17 Platforms: iOS, iPadOS, tvOS, watchOS, visionOS Status: Production-ready pre-flight checklist for App Store submissions

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

最后更新：2026-02-17 平台：iOS, iPadOS, tvOS, watchOS, visionOS 状态：可用于生产环境的App Store提交预提交检查清单

axiom-app-store-submission

Original

Translation

App Store Submission

App Store 提交

Overview

概述

When to Use This Skill

何时使用该技能

Example Prompts

示例提问

1. "Is my app ready to submit to the App Store?"

1. “我的应用是否已准备好提交至App Store？”

2. "What do I need before submitting my first iOS app?"

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

3. "I keep getting rejected, what am I missing?"

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

4. "What's the pre-submission checklist for App Store?"

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

5. "Do I need a privacy manifest?"

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

6. "My app update was rejected for metadata issues"

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

Anti-Patterns

反模式案例

1. Submitting without device testing

1. 未在真机上测试就提交

Build for device

为真机构建

Test critical paths:

测试关键路径：

- Launch → main screen loads

- 启动 → 主界面加载完成

- All tabs/screens accessible

- 所有标签页/界面均可访问

- Core user flows complete without crash

- 核心用户流程可完整执行且无崩溃

- Edge cases: no network, low storage, interruptions

- 边缘场景：无网络、低存储、中断事件

2. Missing or inadequate privacy policy

2. 缺失或不规范的隐私政策

3. Placeholder content left in build

3. 构建包中遗留占位符内容

4. Ignoring privacy manifest

4. 忽略隐私清单

5. Missing Sign in with Apple

5. 缺失Sign in with Apple选项

6. No account deletion flow

6. 无账号删除流程

7. Wrong age rating

7. 年龄分级错误

8. Missing demo credentials

8. 缺失演示账号

Decision Tree

决策树

Mandatory Pre-Flight Checklist

强制预提交检查清单

1. Build Configuration

1. 构建配置

2. Privacy

2. 隐私合规

3. Metadata

3. 元数据

4. Account and Authentication

4. 账号与认证

5. App Review Information

5. App审核信息

6. Content Completeness

6. 内容完整性

7. Regional and Compliance

7. 区域与合规

8. New for 2025-2026

8. 2025-2026年新增要求

Pressure Scenarios

压力场景应对

Scenario 1: "Ship by end of day"

场景1：“今天必须提交”

Scenario 2: "Third rejection, just make it work"

场景2：“第三次被拒，赶紧搞定”

Scenario 3: "It's just a bug fix update"