axiom-app-store-submission by charleswiltgen/axiom
npx skills add https://github.com/charleswiltgen/axiom --skill axiom-app-store-submission系统化的预检清单,可在提交前发现 90% 的 App Store 拒绝原因。核心原则:一次提交,正确提交。超过 40% 的 App Store 拒绝引用准则 2.1(应用完整性)——崩溃、占位符、损坏的链接。另外 30% 是元数据和隐私问题。一个严谨的预检流程可以消除这些可预防的拒绝。
关键洞察:苹果在 2024 年拒绝了近 193 万次提交。大多数拒绝并非政策分歧——而是清单检查失败。30 分钟的预检可以节省 3-7 天的拒绝-修复-重新提交周期。
✅ 在以下情况下使用此技能:
❌ 请勿将此技能用于:
开发者提出的真实问题,此技能可以解答:
该技能提供完整的预检清单,涵盖构建、隐私、元数据、账户、审核信息、内容和地区要求
该技能从头到尾讲解每个要求——隐私清单、元数据字段、截图、演示凭证、年龄分级
该技能提供反模式,包含具体的拒绝原因和识别差距的决策树
该技能提供分类的强制性清单,包含每个如果缺失会触发拒绝的项目
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
是的。自 2024 年 5 月起,缺少隐私清单会导致自动拒绝。该技能解释何时以及如何操作。
该技能涵盖元数据完整性要求和触发准则 2.3 拒绝的常见差距
时间成本:3-7 天(拒绝 + 修复 + 重新提交等待)
症状:因准则 2.1——应用完整性被拒绝。App Review 发现崩溃、流程中断或功能缺失。
❌ 错误做法:仅在模拟器中测试,构建成功即提交
"它在模拟器中运行正常,发布吧"
→ 拒绝:应用在 iPhone 15 Pro 上启动时崩溃(内存限制)
→ 3-7 天延迟
✅ 正确做法:在安装了最新正式版操作系统的物理设备上测试,执行所有用户流程
# 为设备构建
xcodebuild -scheme YourApp \
-destination 'platform=iOS,name=Your iPhone'
# 测试关键路径:
# - 启动 → 主屏幕加载
# - 所有标签页/屏幕可访问
# - 核心用户流程无崩溃完成
# - 边缘情况:无网络、存储空间不足、中断
为何有效:模拟器隐藏了真实设备的限制——内存限制、蜂窝网络行为、硬件特定 API、热节流。App Review 在物理设备上进行测试。
时间成本: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-5 天(拒绝 + 内容替换 + 重新提交)
症状:因准则 2.1——应用完整性被拒绝。审核员发现占位符文本、空屏幕或 TODO 残留物。
❌ 错误做法:发布时包含对用户可见的开发残留物
- 引导中的 "Lorem ipsum" 文本
- 显示 "即将推出" 的空标签页
- 打开提示 "尚未实现" 的按钮
- 默认应用图标(白色网格)
✅ 正确做法:每个屏幕都有最终内容和生产资源
预提交内容审核:
- [ ] 每个屏幕都有真实内容(无 lorem ipsum)
- [ ] 所有图片均为最终生产资源
- [ ] 无 "即将推出" 或 "正在建设中" 的屏幕
- [ ] 所有按钮执行其预期操作
- [ ] 默认/空状态有适当的消息
- [ ] 应用图标是最终的且符合规范(1024x1024,无 alpha 通道)
为何有效:App Review 测试每个屏幕和标签页,包括您可能认为是边缘情况的状态。他们会打开每个菜单、点击每个按钮、切换每个标签页。
时间成本:1-3 天(自动拒绝 + 清单创建 + 重新提交)
症状:在人工审核前自动拒绝。缺少 PrivacyInfo.xcprivacy 或未声明的必需原因 API。
❌ 错误做法:没有隐私清单,或缺少必需原因 API 声明
项目中无 PrivacyInfo.xcprivacy
— 或 —
使用 UserDefaults、文件时间戳、磁盘空间 API
但未声明批准的原因
✅ 正确做法:存在隐私清单,并声明了所有必需原因 API
项目必须包含:
├── PrivacyInfo.xcprivacy
│ ├── NSPrivacyTracking (true/false)
│ ├── NSPrivacyTrackingDomains (if tracking)
│ ├── NSPrivacyCollectedDataTypes (all types)
│ └── NSPrivacyAccessedAPITypes (all Required Reason APIs)
│
└── 第三方 SDK 清单(每个 SDK 包含自己的)
需要声明的常见必需原因 API:
UserDefaults → 原因 CA92.1C617.1E174.135F9.1为何有效:自 2024 年 5 月起,这是一个自动化关卡。不涉及人工审核员——构建处理系统会拒绝缺少必需隐私声明的提交。
时间成本:3-7 天(SIWA 实现 + 重新提交)
症状:因准则 4.8 被拒绝。应用提供第三方登录(Google、Facebook、电子邮件)但没有“通过 Apple 登录”选项。
❌ 错误做法:提供第三方登录但没有 SIWA
// 登录屏幕提供:
// - 通过 Google 登录
// - 通过 Facebook 登录
// - 电子邮件/密码
// ← 缺少:通过 Apple 登录
✅ 正确做法:提供 SIWA 作为与任何第三方登录并列的等效选项
// 登录屏幕提供:
// - 通过 Apple 登录 ← 如果存在其他选项则必需
// - 通过 Google 登录
// - 通过 Facebook 登录
// - 电子邮件/密码
例外情况(不需要 SIWA):
为何有效:准则 4.8 要求只要提供任何第三方或社交登录,就必须提供 SIWA 作为选项。苹果对此严格执行。
时间成本:5-10 天(实现 + 测试 + 重新提交)
症状:因准则 5.1.1(v) 被拒绝。应用允许创建账户但不提供删除账户的方法。
❌ 错误做法:允许创建账户但没有删除能力
- 存在注册按钮
- 应用内任何地方都没有"删除账户"选项
- "联系支持以删除"(不充分)
- "停用账户"(与删除不同)
✅ 正确做法:应用内可访问完整的账户删除流程
账户删除要求:
1. 在设置/个人资料中可发现(非隐藏)
2. 明确标记为"删除账户"(非"停用")
3. 解释删除的含义(数据移除、时间线)
4. 向用户确认完成
5. 如果使用了通过 Apple 登录 → 撤销 SIWA 令牌
6. 如果有活跃订阅 → 通知用户先取消
7. 删除在合理时间内完成(数天,而非数月)
// 撤销通过 Apple 登录令牌(必需)
let appleIDProvider = ASAuthorizationAppleIDProvider()
let request = appleIDProvider.createRequest()
// 用户确认删除后:
// 使用用户的令牌 POST 到 Apple 的撤销端点
// 然后删除服务器端账户数据
为何有效:自 2022 年 6 月起要求。必须是实际删除(非停用),必须在应用内(不仅是电子邮件/网站),并且如果使用了 SIWA 必须撤销令牌。苹果会专门测试此流程。
时间成本:2-4 天(重新回答问卷 + 可能的内容更改 + 重新提交)
症状:因准则 2.3.6——不准确的元数据被拒绝。年龄分级未反映实际应用内容或功能。
❌ 错误做法:低估内容以获得较低分级
应用有用户生成内容(聊天、帖子)
但年龄分级问卷回答"无 UGC"
应用游戏中有卡通暴力
但回答"无暴力"
✅ 正确做法:准确回答年龄分级问卷
如实声明:
- 用户生成内容(聊天、论坛、社交功能)
- 暴力(即使是卡通/幻想)
- 成人主题
- 粗俗语言/粗俗幽默
- 赌博(模拟或真实)
- 恐怖/恐惧主题
- 医疗/治疗信息
- 无限制的网络访问(带有开放 URL 的 WebView)
新年龄分级(2026 年 1 月 31 日):苹果从 4+/9+/12+/17+ 扩展到 5 个层级(4+/9+/13+/16+/18+),并新增了消息传递、UGC、广告和父母控制的能力声明。所有开发者必须完成更新的问卷,否则应用更新将被阻止。
为何有效:不匹配的分级违反准则 2.3.6。苹果会将您的问卷答案与观察到的应用行为进行对比。UGC 和网络访问是最常被遗漏的声明。
时间成本:3-5 天(拒绝 + 凭证创建 + 重新提交等待)
症状:因准则 2.1 被拒绝。审核员无法测试应用,因为需要登录且未提供测试账户。
❌ 错误做法:应用需要登录,但审核备注中没有演示账户
应用审核信息:
备注:(空)
演示账户:(空)
演示密码:(空)
→ 审核员看到登录屏幕,无法继续,拒绝
✅ 正确做法:提供有效的演示凭证和清晰的说明
应用审核信息:
演示账户:demo@yourapp.com
演示密码:AppReview2025!
备注:"使用上面的演示账户登录。
该账户已预加载示例数据。
要测试[功能 X],请导航到标签页 2 > 设置。
如果需要 2FA,请使用代码:123456"
要求:
- 账户在审核期间不得过期(至少 1-2 周)
- 账户必须有代表性的数据
- 包含任何特殊设置步骤
- 如果需要硬件,说明解决方法
- 如果位置特定,提供测试坐标
为何有效:审核员无法测试他们无法访问的内容。他们不会创建自己的账户。如果您的应用需要任何形式的身份验证,演示凭证是强制性的。这是具有登录流程的应用最常见的拒绝原因之一。
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
每次提交前运行此完整清单。检查每个项目,不仅仅是您认为适用的项目。
ITSAppUsesNonExemptEncryption 在 Info.plist 中设置(如果仅使用 HTTPS 则为 NO)PrivacyInfo.xcprivacy 文件存在于应用目标中NS*UsageDescription 用途字符串存在(相机、位置等)背景:产品经理说应用必须在今天提交,以便下周进行营销发布。
压力:截止日期 + 高管可见性
合理化陷阱:
强制性:运行完整的预检清单。每个项目。缺失的项目会导致拒绝,这将花费 3-7 天以上的时间——远比清单所需的 30 分钟更糟糕。
跳过清单以节省 30 分钟,当它导致拒绝时,将花费 3-7 天。
沟通模板:"预检发现了 [N] 个会导致拒绝的问题。修复它们需要 [X 小时]。不修复就提交保证会被拒绝,这至少需要 3-7 天。让我现在修复这些问题——这是最快上线的途径。"
背景:应用因每次不同的问题被拒绝了 3 次。开发者感到沮丧,倾向于偷工减料或与苹果争论。
压力:沮丧 + 沉没成本 + 倾向于上诉而非修复
合理化陷阱:
强制性:阅读每条拒绝消息的完整文本。从头开始运行完整的预检清单。审核员通常在后续审核中发现新问题,因为他们每次都会测试得更深入——他们会探索之前未到达的屏幕,测试之前跳过的流程,并以更严格的态度进行审核。
每次拒绝都表明预提交流程存在差距。不要对抗反馈——吸收它并系统地弥补差距。
沟通模板:"多次拒绝意味着我们有系统性的差距,而不是运气不好。我正在运行完整的预检清单——这需要 30 分钟,但可以防止 3-7 天的部分修复后出现新拒绝的循环。"
背景:简单的单行错误修复。开发者假设更新会顺利通过,因为应用之前已经获得批准。
压力:自满 + 先前批准带来的错误信心
合理化陷阱:
强制性:更新是根据当前指南进行审核的。版本之间的要求会发生变化。隐私清单在周期中变为强制性。年龄分级问卷进行了全面改革。SDK 最低要求每年提高。一个错误修复更新可能因上次版本批准时不存在的问题而被拒绝。
每次都要运行预检清单。上次审核您的应用时不存在的需求现在可能已强制执行。
沟通模板:"即使是错误修复,App Review 也应用当前指南——而不是我们上次获得批准时的指南。隐私清单要求和年龄分级改革都是在周期中出现的。现在运行 30 分钟的预检可以防止意外的拒绝。"
截图必须与当前应用 UI 匹配。有关所需尺寸、尺寸和规则,请参阅 app-store-ref 第 1 部分。
每次拒绝包括:
1. 阅读完整的拒绝消息(每个字)
2. 识别所有引用的准则(可能有多个)
3. 修复所有被引用的问题(不仅仅是第一个)
4. 运行完整的预检清单
5. 在您的重新提交备注中,解释您修复了什么
6. 不要争论或解释为什么您认为拒绝是错误的
上诉适用于以下情况:
上诉不适用于以下情况:
App Store Connect → 解决中心 → 回复
- 清楚解释为什么您认为拒绝是错误的
- 提供具体证据(截图、文档)
- 保持专业和实事求是
- 苹果的 App Review Board 将重新审核
| 类型 | 含义 | 操作 |
|---|---|---|
| 元数据拒绝 | 截图、描述或 ASC 字段需要修复 | 在 ASC 中修复,重新提交(无需新构建) |
| 二进制拒绝 | 代码/应用问题需要修复 | 修复代码,创建新归档,上传新构建 |
IAP 项目需要单独审核。缺少或损坏的 IAP 是准则 3.1.1 下的首要拒绝原因。
❌ "购买高级版" 按钮无任何作用 → 准则 3.1.1
❌ 无恢复购买选项 → 准则 3.1.1
❌ 订阅自动续订未明确披露 → 准则 3.1.2
❌ 购买前未显示免费试用时长 → 准则 3.1.2
❌ 无授权的外部购买链接 → 准则 3.1.1
| 准则 | 问题 | 预防措施 |
|---|---|---|
| 2.1 | 崩溃、功能损坏、不完整 | 设备测试、内容审核 |
| 2.3 | 不准确的元数据、错误的截图 | 截图审核、元数据审查 |
| 2.3.6 | 不正确的年龄分级 | 如实回答问卷、声明 UGC |
| 3.1.1 | IAP 问题、缺少恢复购买 | 测试所有 IAP 流程、添加恢复 |
| 4.0 | 设计:UI 差、非标准模式 | 遵循 HIG、在所有尺寸上测试 |
| 4.8 | 缺少通过 Apple 登录 | 添加 SIWA 与任何第三方登录 |
| 5.1.1(i) | 隐私政策缺失/不充分 | ASC 和应用内均需、具体内容 |
| 5.1.1(v) | 无账户删除 | 应用内删除,不仅是停用 |
| 5.1.2 | 缺少必需原因 API | 完成隐私清单 |
有关 ASC 上传工作流和构建处理详细信息,请参阅 app-store-ref 第 9 部分。
大多数应用需要 ITSAppUsesNonExemptEncryption = false。有关完整决策树,请参阅 app-store-ref 第 5 部分。
无障碍营养标签对新提交逐渐成为必需。有关完整标签列表和声明规则,请参阅 app-store-ref 第 10 部分。在声明前运行 axiom-accessibility-diag。
对于提交第一个应用的开发者,这些是常被遗漏的额外项目。如果您需要从头创建隐私政策,请使用隐私政策生成器(有许多免费选项)并根据您应用的实际数据实践进行定制——通用模板将被拒绝。
| 错误 | 结果 | 修复 |
|---|---|---|
| Xcode 和 ASC 之间的包标识符不匹配 | 上传被拒绝 | 完全匹配,包括大小写 |
| 分发证书过期/缺失 | 归档上传失败 | 在 Developer Portal 中创建新证书 |
| 许可协议未接受 | 上传被阻止 | 在 developer.apple.com 接受 |
| 税务表格不完整 | 付费应用不分发 | 在 ASC → 协议、税务和银行业务中完成 |
| 在 Xcode 中选择了错误的团队 | 签名错误 | 在签名与功能中选择正确的团队 |
之前:开发者未使用清单提交 → 因缺少隐私清单被拒绝(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
每周安装
42
仓库
GitHub 星标
601
首次出现
2026 年 2 月 18 日
安全审计
安装于
codex40
opencode39
github-copilot38
gemini-cli38
kimi-cli37
amp37
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.
✅ Use this skill when :
❌ Do NOT use this skill for :
Real questions developers ask that this skill answers:
The skill provides a complete pre-flight checklist covering build, privacy, metadata, accounts, review info, content, and regional requirements
The skill walks through every requirement from scratch — privacy manifest, metadata fields, screenshots, demo credentials, age rating
The skill provides anti-patterns with specific rejection causes and the decision tree to identify gaps
The skill provides a categorized mandatory checklist with every item that triggers rejection if missing
Yes. Since May 2024, missing privacy manifests cause automatic rejection. The skill explains when and how.
The skill covers metadata completeness requirements and the common gaps that trigger Guideline 2.3 rejections
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
# 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.
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.
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.
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.1C617.1E174.135F9.1Why it works : Since May 2024, this is an automated gate. No human reviewer involved — the build processing system rejects submissions missing required privacy declarations.
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
// 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
// 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):
Why it works : Guideline 4.8 requires SIWA as an option whenever ANY third-party or social login is offered. Apple enforces this strictly.
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)
// 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.
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.
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.
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
Run this entire checklist before every submission. Check every item, not just the ones you think apply.
ITSAppUsesNonExemptEncryption set in Info.plist (NO if only HTTPS)PrivacyInfo.xcprivacy file present in app targetNS*UsageDescription purpose strings present (Camera, Location, etc.)Setup : PM says the app must be submitted today for a marketing launch next week.
Pressure : Deadline + executive visibility
Rationalization traps :
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."
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 :
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."
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 :
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."
Screenshots must match current app UI. See app-store-ref Part 1 for required sizes, dimensions, and rules.
Every rejection includes:
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
Appeals are appropriate when:
Appeals are NOT appropriate when:
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
| 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 |
IAP items require separate review. Missing or broken IAP is a top rejection cause under Guideline 3.1.1.
❌ "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
| 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 |
See app-store-ref Part 9 for the ASC upload workflow and build processing details.
Most apps need ITSAppUsesNonExemptEncryption = false. See app-store-ref Part 5 for the full decision tree.
Accessibility Nutrition Labels are becoming required for new submissions. See app-store-ref Part 10 for the full label list and declaration rules. Run axiom-accessibility-diag before declaring.
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.
| 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 |
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.
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, axiom-app-store-connect-ref
Weekly Installs
42
Repository
GitHub Stars
601
First Seen
Feb 18, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
codex40
opencode39
github-copilot38
gemini-cli38
kimi-cli37
amp37
LLM结构化输出提取器:从AI响应中提取类型化数据的完整指南
70 周安装
SwiftUI动画完全指南:从Animatable协议到iOS 26的@Animatable宏
195 周安装
Feishu Image Sender - 向飞书/Lark发送图片的CLI工具和Node.js库
193 周安装
如何向AI工作流添加新技能?GitHub技能下载与文档更新完整指南
194 周安装
FPGA开发专家指南:Vivado、SystemVerilog硬件设计优化与高级技术实践
196 周安装
iOS UI 开发专家指南:SwiftUI、UIKit、布局、导航、动画与设计问题一站式解决方案
194 周安装
| Complete privacy manifest |