1
This commit is contained in:
290
docs/app-store-submission-checklist-2026-03-07.md
Normal file
290
docs/app-store-submission-checklist-2026-03-07.md
Normal file
@@ -0,0 +1,290 @@
|
||||
# KeyBoard 提审前清单
|
||||
|
||||
更新日期：2026-03-07
|
||||
|
||||
本文档基于两部分信息整理：
|
||||
|
||||
1. 当前工程静态检查结果与最近几轮已修复项
|
||||
2. Apple 截至 2026-03-07 仍公开可查的官方要求
|
||||
|
||||
目标不是“理论合规”，而是尽量提高这次送审的一次通过率。
|
||||
|
||||
## 一、当前判断
|
||||
|
||||
项目本身不属于明显的违规型产品，主要风险集中在：
|
||||
|
||||
1. 审核员是否能顺畅走完 `安装 App -> 启用键盘 -> 开启 Full Access -> 登录 -> 使用 AI -> 购买/恢复购买`
|
||||
2. `RequestsOpenAccess = true` 的隐私披露、权限说明、App Privacy 申报、隐私政策正文是否完全一致
|
||||
3. AI / persona / 语音相关内容是否有足够明确的内容安全与举报处理机制
|
||||
4. 订阅、协议、隐私、元数据是否存在“能点但不清楚”或“描述过度”的情况
|
||||
|
||||
## 二、目前已完成
|
||||
|
||||
以下项已经处理，不再是当前最高风险：
|
||||
|
||||
1. 协议、隐私政策、会员协议入口已经从空实现改为真实跳转/真实页面兜底
|
||||
2. `KBWebViewViewController` 的链接错误已经修复
|
||||
3. Web 页返回箭头被遮挡的问题已经修复
|
||||
4. `KBPayMainVC` 的 `restoreButton` 英文文案显示不全问题已经修复
|
||||
5. 重复的 `Shared` / `KBConfig` / `KBAuthManager` 历史副本已经收敛为顶层 [Shared](/Users/mac/Desktop/项目/公司/KeyBoard/Shared)
|
||||
|
||||
注意：协议入口虽然已经打通，但如果你还没换成正式线上 URL，这一项只能算“代码层打通”，不算“提审完成”。
|
||||
|
||||
## 三、提审前必须完成
|
||||
|
||||
### 1. 替换正式协议 URL 和正式正文
|
||||
|
||||
必须完成：
|
||||
|
||||
1. 在 [KBConfig.h](/Users/mac/Desktop/项目/公司/KeyBoard/Shared/KBConfig.h) 中填入正式线上地址：
|
||||
- `KB_TERMS_OF_SERVICE_URL`
|
||||
- `KB_PRIVACY_POLICY_URL`
|
||||
- `KB_MEMBERSHIP_AGREEMENT_URL`
|
||||
2. 确保线上页面不是占位页，不是空白页，不是“敬请期待”
|
||||
3. 确保协议正文明确写清：
|
||||
- 收集哪些数据
|
||||
- 是否上传键入文本
|
||||
- 是否上传语音
|
||||
- 上传目的
|
||||
- 是否用于模型训练
|
||||
- 数据保留时长
|
||||
- 如何删除账号与数据
|
||||
4. 确保 App 内文案、隐私政策、App Store Connect 的 App Privacy 三者完全一致
|
||||
|
||||
对应风险：
|
||||
|
||||
1. `2.1 App Completeness`
|
||||
2. `2.3.1 Accurate Metadata`
|
||||
3. `5.1.1 Data Collection and Storage`
|
||||
|
||||
### 2. 完成 App Store Connect 的 App Privacy 申报
|
||||
|
||||
必须完成：
|
||||
|
||||
1. 逐项盘清主 App 与键盘扩展到底收集了什么
|
||||
2. 对以下类型重点核对是否需要申报：
|
||||
- 账号信息
|
||||
- 用户内容
|
||||
- 音频数据
|
||||
- 诊断数据
|
||||
- 使用数据
|
||||
- 购买信息
|
||||
3. 明确区分：
|
||||
- 仅设备本地处理
|
||||
- 会发往你方服务器
|
||||
- 会共享给第三方 SDK
|
||||
4. 如果某项在键盘扩展里只在 Full Access 后发生，也要按“App 整体最全面数据实践”申报
|
||||
|
||||
重点核对问题：
|
||||
|
||||
1. 开启 Full Access 后是否会发送键入内容到服务端
|
||||
2. 语音输入是否上传服务器做识别或生成
|
||||
3. 是否保存聊天内容、persona 对话、历史输入、账号数据
|
||||
4. 是否有埋点、诊断、崩溃、分析 SDK
|
||||
|
||||
对应风险：
|
||||
|
||||
1. `5.1.1`
|
||||
2. App Privacy 填报不实导致的审核驳回
|
||||
|
||||
### 3. 写清楚 Review Notes
|
||||
|
||||
这是你这类键盘 App 的高优先级项。
|
||||
|
||||
必须写进 Review Notes：
|
||||
|
||||
1. 审核设备上如何启用键盘
|
||||
2. 如何在系统设置里打开 Full Access
|
||||
3. 哪些功能在键盘扩展内可以直接完成
|
||||
4. 哪些功能会拉起主 App 完成
|
||||
5. 登录路径
|
||||
6. 购买路径
|
||||
7. 恢复购买路径
|
||||
8. 提供可直接使用的测试账号
|
||||
9. 如果 AI、语音、订阅依赖服务器，确认服务在审核期保持可用
|
||||
|
||||
建议写法要点：
|
||||
|
||||
1. 用步骤写，不要写泛泛描述
|
||||
2. 写清楚“如果 reviewer 没开 Full Access，会看到什么”
|
||||
3. 写清楚“为什么某些购买/登录操作会跳回主 App”
|
||||
|
||||
对应风险：
|
||||
|
||||
1. `2.1 App Completeness`
|
||||
2. 审核员误判“功能不可用”
|
||||
|
||||
### 4. 补齐 AI / persona / 语音的内容安全兜底
|
||||
|
||||
必须完成：
|
||||
|
||||
1. 确认服务端存在内容审核或关键词/策略拦截
|
||||
2. 对以下类型有最基本的拦截策略：
|
||||
- 成人/性暗示
|
||||
- 仇恨/歧视
|
||||
- 骚扰/威胁
|
||||
- 自残/极端危险内容
|
||||
3. App 内明确保留举报入口，并保证流程可用
|
||||
4. 如果存在用户生成的人设、头像、简介、评论，也要有举报与处理机制
|
||||
|
||||
建议补充：
|
||||
|
||||
1. 在 AI 页面补一段简短说明，明确“内容由 AI 生成，可能不准确”
|
||||
2. 在审核备注里说明你有内容审核、举报与处理机制
|
||||
|
||||
对应风险：
|
||||
|
||||
1. `1.1 Objectionable Content`
|
||||
2. `1.2 User-Generated Content`
|
||||
3. `4.7` 涉及聊天/插件型软件时的过滤与举报要求
|
||||
|
||||
### 5. 订阅展示与订阅元数据核对完成
|
||||
|
||||
必须完成：
|
||||
|
||||
1. 订阅页显示内容与 App Store Connect 配置一致
|
||||
2. 恢复购买入口可用
|
||||
3. 订阅页能访问隐私政策和 Terms / EULA
|
||||
4. 审核员能明确知道购买后获得什么权益
|
||||
5. 如果有试用、周期、价格说明，必须准确
|
||||
|
||||
同时核对：
|
||||
|
||||
1. App 描述、截图、预览里是否把付费能力说清楚
|
||||
2. 是否把本来受限于订阅的能力误写成所有用户都可用
|
||||
|
||||
对应风险：
|
||||
|
||||
1. `3.1.1`
|
||||
2. `3.1.2`
|
||||
3. `2.3.2`
|
||||
|
||||
### 6. 元数据降承诺，避免夸大
|
||||
|
||||
必须完成：
|
||||
|
||||
1. 商店描述不要写成“任何 App 都可稳定使用全部 AI / 语音 / 登录 / 购买能力”
|
||||
2. 明确第三方键盘天然限制：
|
||||
- 安全输入框不可用
|
||||
- 某些系统场景不可用
|
||||
- 某些能力依赖 Full Access
|
||||
3. 不要写“全场景可用”“所有输入框可用”“无需切换即可全部完成”
|
||||
|
||||
对应风险：
|
||||
|
||||
1. `2.3.1 Accurate Metadata`
|
||||
|
||||
### 7. 真机完整走查一遍
|
||||
|
||||
必须在真机上完成，不建议只看模拟器：
|
||||
|
||||
1. 首装 App
|
||||
2. 注册 / 登录
|
||||
3. Apple 登录
|
||||
4. 账号注销
|
||||
5. 启用键盘
|
||||
6. 开启 Full Access
|
||||
7. 键盘 AI 输入
|
||||
8. 语音输入
|
||||
9. 拉起主 App 登录
|
||||
10. 拉起主 App 购买
|
||||
11. 恢复购买
|
||||
12. 协议 / 隐私政策 / 会员协议打开
|
||||
13. 断网 / 弱网 / 未登录 / 未开 Full Access 的兜底提示
|
||||
|
||||
审核关注的是“能不能稳定用”，不是“你本地跑通过一次”。
|
||||
|
||||
## 四、建议在提审前也完成
|
||||
|
||||
### 1. 准备一套专门给审核员的测试路径
|
||||
|
||||
建议准备：
|
||||
|
||||
1. 一个可登录测试账号
|
||||
2. 一组固定可复现的 persona / AI 演示输入
|
||||
3. 一条可稳定触发订阅购买页的路径
|
||||
4. 一条可稳定触发恢复购买的路径
|
||||
|
||||
### 2. 核对权限申请时机与文案
|
||||
|
||||
建议检查：
|
||||
|
||||
1. 麦克风权限是否只在真正开始语音功能时再申请
|
||||
2. 权限文案是否说明真实用途
|
||||
3. 是否存在“先要权限，功能再解释”的情况
|
||||
|
||||
### 3. 做一次审核视角的异常测试
|
||||
|
||||
建议故意测试：
|
||||
|
||||
1. 未登录直接进 AI
|
||||
2. 未开 Full Access 直接进扩展高级功能
|
||||
3. 服务端异常
|
||||
4. IAP 商品加载失败
|
||||
5. 协议 URL 打不开
|
||||
|
||||
目标是让 reviewer 遇到异常时也能理解，不会直接判“不可用”。
|
||||
|
||||
## 五、提交物料清单
|
||||
|
||||
提审前建议你准备好以下材料：
|
||||
|
||||
1. 最终版隐私政策 URL
|
||||
2. 最终版 Terms / 会员协议 URL
|
||||
3. App Store Connect 的 App Privacy 填报截图或内部核对表
|
||||
4. Review Notes
|
||||
5. 测试账号
|
||||
6. 订阅商品配置清单
|
||||
7. 审核演示路径截图或内部 SOP
|
||||
|
||||
## 六、建议的最终提审门槛
|
||||
|
||||
至少满足下面这些条件再点提交：
|
||||
|
||||
1. 所有协议/隐私/会员协议入口都能打开正式内容
|
||||
2. App Privacy、隐私政策、权限文案、Review Notes 四者一致
|
||||
3. 审核员不用猜你产品流程，就能完成键盘启用、登录、AI、订阅体验
|
||||
4. AI / persona / 语音内容有明确的审核与举报机制
|
||||
5. 真机完整走查至少 1 遍，最好 2 台设备、2 个语言环境
|
||||
|
||||
## 七、你现在最值得优先做的 5 件事
|
||||
|
||||
按优先级排序：
|
||||
|
||||
1. 填正式协议 URL，并把正文改成最终版
|
||||
2. 完成 App Store Connect 的 App Privacy 申报核对
|
||||
3. 写最终版 Review Notes，并准备测试账号
|
||||
4. 核实 AI / 语音 / persona 的内容安全与举报闭环
|
||||
5. 真机完整跑通 `启用键盘 -> Full Access -> 登录 -> AI -> 订阅 -> 恢复购买`
|
||||
|
||||
## 八、官方参考
|
||||
|
||||
以下页面均为 Apple 官方来源，已于 2026-03-07 核对：
|
||||
|
||||
1. App Review Guidelines
|
||||
https://developer.apple.com/app-store/review/guidelines/
|
||||
2. Offering account deletion in your app
|
||||
https://developer.apple.com/support/offering-account-deletion-in-your-app/
|
||||
3. Manage app privacy
|
||||
https://developer.apple.com/help/app-store-connect/manage-app-information/manage-app-privacy
|
||||
4. App Privacy Details
|
||||
https://developer.apple.com/app-store/app-privacy-details/
|
||||
5. Creating a custom keyboard / Custom Keyboard guidance
|
||||
https://developer.apple.com/documentation/UIKit/creating-a-custom-keyboard
|
||||
https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/CustomKeyboard.html
|
||||
|
||||
## 九、备注
|
||||
|
||||
这份清单是“上架执行清单”，不是法律意见，也不是 Apple 的通过保证。
|
||||
|
||||
如果按当前工程状态直接提，风险仍主要集中在：
|
||||
|
||||
1. 隐私披露不一致
|
||||
2. 审核员走不通键盘链路
|
||||
3. AI 内容安全证据不足
|
||||
4. 元数据对键盘能力描述过满
|
||||
|
||||
如果你要继续推进，下一步最值钱的是再补两份文档：
|
||||
|
||||
1. `Review Notes` 最终版
|
||||
2. `App Privacy / 隐私政策披露对照表`
|
||||
254
docs/privacy-alignment-matrix-2026-03-08.md
Normal file
254
docs/privacy-alignment-matrix-2026-03-08.md
Normal file
@@ -0,0 +1,254 @@
|
||||
# KeyBoard 隐私披露对照表
|
||||
|
||||
更新日期：2026-03-08
|
||||
|
||||
## 1. 这份表是干什么的
|
||||
|
||||
这份表专门回答一件事：
|
||||
|
||||
`App 内文案`、`隐私政策`、`App Store Connect 的 App Privacy` 应该如何对齐，避免三处口径打架。
|
||||
|
||||
你可以把它当成提审前的“隐私总对照表”。
|
||||
|
||||
## 2. Apple 当前口径
|
||||
|
||||
结合 Apple 截至 2026-03-08 的官方文档，当前需要特别记住 4 个点：
|
||||
|
||||
1. 你需要申报你自己和第三方 SDK 从 App 中收集的数据。
|
||||
2. “收集”通常指数据离开设备，并且你或第三方可以以可读形式访问超出实时处理所需的时间。
|
||||
3. 免费文本框和语音录音通常对应：
|
||||
- `Other User Content`
|
||||
- `Audio Data`
|
||||
4. 对第三方键盘来说，开启 `Full Access` 后如果会把键入内容或语音发到服务器，必须明确告诉用户，而且文案必须和实际行为一致。
|
||||
|
||||
官方来源：
|
||||
|
||||
1. App Privacy Details
|
||||
https://developer.apple.com/app-store/app-privacy-details/
|
||||
2. App Privacy（App Store Connect Help）
|
||||
https://developer.apple.com/help/app-store-connect/reference/app-privacy
|
||||
3. App Extension Programming Guide: Custom Keyboard
|
||||
https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/CustomKeyboard.html
|
||||
|
||||
## 3. 当前工程里已经看到的事实
|
||||
|
||||
以下结论来自当前代码，不是猜测：
|
||||
|
||||
1. 主 App 和键盘扩展都声明了麦克风权限。
|
||||
- `keyBoard/Info.plist`
|
||||
- `CustomKeyboard/Info.plist`
|
||||
2. 键盘扩展开启了 `RequestsOpenAccess = true`。
|
||||
- `CustomKeyboard/Info.plist`
|
||||
3. 主 App 存在语音录音，并把录音文件上传到服务端做转写。
|
||||
- `AiVM.m` 中有 `uploadFile:API_AI_SPEECH_TRANSCRIBE`
|
||||
4. AI 文本内容会发到服务端。
|
||||
- `AiVM.m`
|
||||
- `CustomKeyboard/VM/KBVM.m`
|
||||
5. 存在账号体系，会保存 email、userId、token、用户资料。
|
||||
- `KBUserSessionManager`
|
||||
- `KBAuthManager`
|
||||
- `KBMyVM`
|
||||
6. 存在头像上传。
|
||||
- `KBMyVM.m`
|
||||
7. 存在购买记录 / 钱包流水 / 订阅恢复。
|
||||
- `KBMyVM.m`
|
||||
- 支付相关 VC / StoreKit 桥接
|
||||
8. Release 下启用了 Bugly。
|
||||
- `AppDelegate.m`
|
||||
9. 工程里有自定义埋点上报器 `KBMaiPointReporter`，默认 Release 关闭，但如果你通过宏配置线上地址，则会真正上传。
|
||||
10. 当前 [PrivacyInfo.xcprivacy](/Users/mac/Desktop/项目/公司/KeyBoard/keyBoard/PrivacyInfo.xcprivacy) 只声明了：
|
||||
- `Email Address`
|
||||
- `User ID`
|
||||
- `Other User Content`
|
||||
这和当前代码能力相比，大概率不完整。
|
||||
|
||||
## 4. 对照原则
|
||||
|
||||
每一项数据，都用同一套问题去核对：
|
||||
|
||||
1. 是否真的收集？
|
||||
2. 是本地处理，还是上传服务端？
|
||||
3. 上传只是实时处理，还是会保存？
|
||||
4. 是否与账号关联？
|
||||
5. 用途是功能、个性化、分析、诊断，还是别的？
|
||||
|
||||
只要任意一项在三处说法不一致，就有审核风险。
|
||||
|
||||
## 5. 核心对照表
|
||||
|
||||
| 数据主题 | 当前代码证据 | App 内文案应该怎么说 | 隐私政策应该怎么写 | App Privacy 建议填写 | 当前状态 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 账号邮箱 | 登录 / 用户信息 / `PrivacyInfo.xcprivacy` 已声明 `EmailAddress` | 明确告诉用户邮箱用于注册、登录、找回账号、账号识别 | 写明会收集邮箱，用于账号认证、登录、客服、账号找回；是否保存、保存多久、如何删除 | `Email Address`；通常 `Linked = Yes`；`Purpose = App Functionality` | 基本已覆盖，但要核对隐私政策正文是否真的写了 |
|
||||
| 用户 ID / 账号标识 | `KBUserSessionManager`、`KBAuthManager`、`PrivacyInfo.xcprivacy` 已声明 `UserID` | 告知用户登录后会生成并使用账号标识，以维持登录态和同步功能 | 写明会保存账号 ID / token / 账号资料，用于身份验证、同步和安全 | `User ID`；通常 `Linked = Yes`；`Purpose = App Functionality` | 基本已覆盖，但隐私政策和后台要保持一致 |
|
||||
| AI 输入文本 / 聊天内容 | `AiVM requestChatMessageWithContent`；`KBVM sendChatMessageWithContent`；聊天记录接口 | 如果用户主动使用 AI、改写、聊天等网络功能，应明确提示“你发送的文本会被传输到服务器处理” | 写明：当用户主动触发 AI 功能时，输入文本、聊天内容和必要上下文可能被上传，用于生成回复、同步记录或安全处理；是否保存、保存多久、是否用于训练必须写清 | 至少评估 `Other User Content`；通常 `Linked = Yes`；`Purpose = App Functionality` | 当前 `PrivacyInfo.xcprivacy` 已有 `OtherUserContent`，但隐私政策正文和 App 内文案还需要更明确 |
|
||||
| 键盘内输入文本 | 键盘扩展开启 `Full Access`，且键盘内 AI 文本请求会出网 | 不能只写“开启 Full Access 体验全部功能”；必须补一句“仅当你主动使用联网功能时，相关输入内容可能被发送到服务器处理” | 必须明确区分：普通本地输入 vs 用户主动触发的 AI / 联网功能；哪些情况下键入内容会离开设备；是否保留；是否和账号关联 | 若仅实时处理且不保留，按 Apple 口径可能不一定算“collect”；但只要会保留或超出实时处理，就按 `Other User Content` 申报。审核上建议按最保守口径写清 | 这是当前最敏感项，必须你和后端最终确认 |
|
||||
| 语音录音 / 语音转文字 | `KBAIHomeVC` 录音后调用 `transcribeAudioFileAtURL:`；`AiVM` 上传 `audio/m4a` 到 `/speech/transcribe` | 麦克风权限文案不能只写“用于语音输入”，还应在功能说明里告诉用户“录音会上传到服务器进行识别/转写”，如果确实如此 | 必须写明是否上传语音文件、是否只用于转写、是否保存原始音频、保存多久、是否用于训练模型 | `Audio Data`；通常 `Linked = Yes`；`Purpose = App Functionality` | 当前代码层面已经能确认“主 App 语音录音会上传做转写”，但 `PrivacyInfo.xcprivacy` 还没体现 |
|
||||
| AI 生成音频 / 音频 URL | `/chat/audio/{audioId}` 获取 AI 音频 URL | 可不单独强调为“用户数据”，但如果会和聊天记录一起保存，可在 AI 说明里写清 | 若服务端会保存 AI 语音内容，建议在隐私政策里说明与聊天内容的关系和保留策略 | 一般不单独作为新的用户数据类型填写，除非其中包含用户上传的语音原件或和用户行为绑定用于分析 | 需要结合服务端保留策略判断 |
|
||||
| 头像上传 | `KBMyVM upLoadAvatarWithData:` 上传 `avatar.jpg` | 如果用户上传头像，界面需明确“头像将上传并用于个人资料展示” | 写明会收集用户上传的头像图片，用于个人资料展示与账号信息维护；写清删除方式 | 评估 `Photos or Videos`；通常 `Linked = Yes`；`Purpose = App Functionality` | 当前代码已存在上传；App Privacy 很可能漏填 |
|
||||
| 昵称 / 基本资料 | `updateUserInfo` 会上传 `nickName`、`gender`、`avatarUrl` | 界面上应明确这些资料用于完善个人主页、账号展示或个性化体验 | 隐私政策写清用户资料字段、用途、是否公开展示、如何删除 | `Name` 可能需要评估；`gender` 需结合业务含义进一步评估是否属于普通资料还是敏感信息 | 这项需要你最终按真实展示逻辑确认 |
|
||||
| 购买记录 / 钱包流水 / 订阅状态 | `fetchWalletTransactionsWithPage`、订阅页、恢复购买 | 订阅页和个人页要清楚说明购买后会记录订阅状态和消费记录 | 写明会处理订阅状态、订单/消费记录，用于开通权益、恢复购买、客服和对账 | 评估 `Purchase History`；通常 `Linked = Yes`；`Purpose = App Functionality` | 当前代码已有相关能力，App Privacy 大概率还没覆盖 |
|
||||
| 反馈内容 | `submitFeedbackWithContent:` | 反馈页应说明“你提交的反馈内容将用于客服和问题处理” | 写明反馈内容仅用于客服、问题排查、产品支持，是否保存以及保留时长 | 可评估 `Customer Support`；若完全满足 Apple“可选披露”四条件，可不申报；不满足则申报 | 取决于你是否想走“可选披露”路径；为了稳，通常建议披露 |
|
||||
| 举报内容 / 举报原因 / 聊天证据 | `reportCompanionWithCompanionId` 包含 `reportDesc`、`chatContext`、`evidenceImageUrl` | 举报页面应明确“举报内容和相关上下文将用于审核处理” | 写明会处理举报描述、聊天上下文、证据链接，用于安全审核与申诉处理 | 通常优先评估 `Customer Support` 或 `Other User Content`；如有用户上传图片，还要评估 `Photos or Videos` | 建议明确披露，不建议藏着不说 |
|
||||
| 崩溃日志 / 诊断 | Release 启用 Bugly | App 内通常不用强提示，但隐私政策要写明使用第三方崩溃诊断服务 | 写明会收集崩溃和诊断信息，用于修复问题、提升稳定性；是否关联用户需按 SDK 实际行为确认 | 至少评估 `Crash Data`；必要时再评估 `Performance Data` / `Other Diagnostic Data` | 当前最需要你确认 Bugly 实际上传字段；如果保留 Release Bugly，不能忽略 |
|
||||
| 埋点 / 用户交互数据 | `KBMaiPointReporter` 会上传 `eventName / page_id / element_id / token`；默认 Release 关闭，但可被宏开启 | 如果 Release 真的开启埋点，App 内至少要在隐私政策里说明会收集使用行为数据用于分析和优化 | 写明会收集页面曝光、点击、功能使用等行为数据；是否绑定账号、是否用于分析、是否与第三方共享 | 如 Release 开启，评估 `Product Interaction`；通常 `Linked = Yes`；`Purpose = Analytics`，必要时也可能 `App Functionality` | 当前代码默认 Release 关闭；若提审包不启用，可不按已收集算；若线上宏打开，就必须申报 |
|
||||
| AppGroup / 本地缓存 / 本地文件 | `NSUserDefaults`、App Group、persona 图片、本地录音文件 | 本地缓存通常不需要单独对用户解释成“上传收集”，但可在隐私政策里说明用于本地功能和跨 App/扩展同步 | 若仅本地处理、不离开设备，通常不属于 App Privacy 的“Collected” | 通常不需要在 App Privacy 填“收集”，除非它们会再被上传或长期保存到服务端 | 这一类要和“真正上传到服务器的数据”区分清楚 |
|
||||
|
||||
## 6. 当前最可能不一致的地方
|
||||
|
||||
按当前代码和现状，以下几项最容易出现“三处不一致”：
|
||||
|
||||
### 6.1 语音数据
|
||||
|
||||
当前代码已经能看出：
|
||||
|
||||
1. 主 App 会录音
|
||||
2. 录音文件会上传到 `/speech/transcribe`
|
||||
|
||||
如果你现在：
|
||||
|
||||
1. App 内只写“用于语音输入”
|
||||
2. 隐私政策没写“上传服务器做识别”
|
||||
3. App Privacy 没勾 `Audio Data`
|
||||
|
||||
那就是明显不一致。
|
||||
|
||||
### 6.2 键盘 Full Access 后的输入内容
|
||||
|
||||
当前代码能看出：
|
||||
|
||||
1. 键盘扩展启用了 `RequestsOpenAccess = true`
|
||||
2. 键盘中的 AI 联网能力会把用户主动触发的文本请求发到服务端
|
||||
|
||||
如果你现在：
|
||||
|
||||
1. App 内只写“开启 Full Access 体验全部功能”
|
||||
2. 隐私政策没区分“何时会把输入发送到服务端”
|
||||
3. Review Notes 也没写清
|
||||
|
||||
这会是审核重点风险。
|
||||
|
||||
### 6.3 头像图片
|
||||
|
||||
当前代码里头像上传已经存在。
|
||||
|
||||
如果你现在：
|
||||
|
||||
1. 隐私政策没提用户上传图片
|
||||
2. App Privacy 没评估 `Photos or Videos`
|
||||
|
||||
这也是不一致。
|
||||
|
||||
### 6.4 崩溃日志 / 诊断
|
||||
|
||||
当前 Release 有 Bugly。
|
||||
|
||||
如果你现在：
|
||||
|
||||
1. 隐私政策没提崩溃诊断
|
||||
2. App Privacy 也没申报 `Crash Data`
|
||||
|
||||
那至少需要复核，不能直接默认没收集。
|
||||
|
||||
### 6.5 购买记录
|
||||
|
||||
当前代码里存在：
|
||||
|
||||
1. 订阅
|
||||
2. 恢复购买
|
||||
3. 钱包流水 / 消费记录查询
|
||||
|
||||
如果你现在：
|
||||
|
||||
1. 会员协议只写订阅，不写记录和恢复购买相关处理
|
||||
2. App Privacy 没评估 `Purchase History`
|
||||
|
||||
这项也不完整。
|
||||
|
||||
## 7. 你现在可以直接照着改的口径
|
||||
|
||||
下面不是最终法律文本，而是“先把口径统一”的写法模板。
|
||||
|
||||
### 7.1 App 内关于 Full Access 的文案建议
|
||||
|
||||
当前类似文案：
|
||||
|
||||
`Turn on Allow Full Access to experience all features`
|
||||
|
||||
建议补充为类似意思：
|
||||
|
||||
`开启 Full Access 后，键盘可使用联网功能。仅当你主动使用 AI、账号、同步、订阅或语音等联网功能时，相关文本、语音或必要账号信息可能被发送到服务器处理。`
|
||||
|
||||
### 7.2 App 内关于麦克风 / 语音的文案建议
|
||||
|
||||
当前权限文案：
|
||||
|
||||
`需要使用麦克风进行语音输入`
|
||||
|
||||
建议在功能页或权限前说明里再补一句：
|
||||
|
||||
`录制的语音会上传到服务器进行识别/转写，用于把语音转换为文本。`
|
||||
|
||||
如果你们实际不保存原始音频，再补一句：
|
||||
|
||||
`原始音频仅用于完成本次识别请求，不作其他用途。`
|
||||
|
||||
前提是这句话必须和真实后端行为一致。
|
||||
|
||||
### 7.3 隐私政策里 AI / 聊天 / 键盘文本的建议写法
|
||||
|
||||
建议至少写清 5 件事：
|
||||
|
||||
1. 用户主动触发哪些功能时，文本会离开设备
|
||||
2. 是否会上传聊天内容和上下文
|
||||
3. 是否会保留聊天记录
|
||||
4. 是否用于模型训练
|
||||
5. 如何删除账号和相关数据
|
||||
|
||||
### 7.4 App Privacy 后台填写的建议思路
|
||||
|
||||
按当前代码，至少应重新复核这些数据类型：
|
||||
|
||||
1. `Email Address`
|
||||
2. `User ID`
|
||||
3. `Other User Content`
|
||||
4. `Audio Data`
|
||||
5. `Photos or Videos`
|
||||
6. `Purchase History`
|
||||
7. `Crash Data`
|
||||
8. `Customer Support`
|
||||
9. `Product Interaction`
|
||||
|
||||
其中：
|
||||
|
||||
1. `Product Interaction` 取决于 Release 是否真正开启埋点
|
||||
2. `Crash Data` 取决于 Release Bugly 是否真实上传
|
||||
3. `Audio Data`、`Photos or Videos`、`Purchase History` 基本都值得重点复核
|
||||
|
||||
## 8. 当前我对你项目的直接判断
|
||||
|
||||
如果现在立刻去填 `App Privacy`，最危险的不是“完全没法填”，而是“容易少填或写得太轻”。
|
||||
|
||||
按当前代码，我更倾向于你至少要重点确认：
|
||||
|
||||
1. `Audio Data`
|
||||
2. `Other User Content`
|
||||
3. `Photos or Videos`
|
||||
4. `Purchase History`
|
||||
5. `Crash Data`
|
||||
|
||||
当前 [PrivacyInfo.xcprivacy](/Users/mac/Desktop/项目/公司/KeyBoard/keyBoard/PrivacyInfo.xcprivacy) 只写了 `Email / User ID / Other User Content`，明显不足以覆盖你现有功能边界。
|
||||
|
||||
## 9. 下一步建议
|
||||
|
||||
我建议你马上做两件事：
|
||||
|
||||
1. 让产品 / 后端 / 你自己确认“语音、键盘文本、聊天内容、头像、崩溃日志、埋点”的真实保留策略
|
||||
2. 然后基于这张表去统一：
|
||||
- App 内提示文案
|
||||
- 隐私政策正文
|
||||
- App Store Connect 的 App Privacy
|
||||
|
||||
如果你愿意，我下一步可以继续直接帮你出两份可提交材料：
|
||||
|
||||
1. 一版可直接粘到 Apple 后台的 `App Privacy 填写建议`
|
||||
2. 一版可直接放到网页里的 `隐私政策补充段落`
|
||||
Reference in New Issue
Block a user