AI 生成应用上架前的五项检查

AI 帮你把应用做出来，不等于帮你把应用送上商店。作者列出的五个审核风险，集中在网页套壳、社交登录、账号删除、审核访问和隐私披露。它们经常不影响演示，却可能卡住提交。

这份清单适合准备把 AI 生成的应用上架的开发者：界面之外，还要检查账号、数据和后台服务是否形成完整闭环。不过，作者没有提供审核通过率或对照实验，部分表述也需要结合具体应用理解。

能在手机上打开，还不够成为合格应用

作者首先提醒的是 Apple 的 4.2 条款：应用需要在功能、内容和界面上，超出对网站的简单重新包装。

如果 AI builder 生成的是网页，再用 WebView 套一层外壳，作者认为这正是常见的拒审风险。他建议采用原生构建，并提到 React Native/Expo 输出、推送、离线处理和面向手机设计的页面，都有助于改善应用体验。

对前端开发者来说，关键在于区分两个验收目标：网页能否运行，以及应用是否提供了适合手机的体验。把响应式页面放进安装包，只完成了前一个目标。

但原文没有证明，换成 React Native/Expo 就一定能通过 4.2。框架名称只能说明实现方式，不能代替功能和体验本身。

登录做得越快，越容易漏掉账号的出口

第二项是 Apple 的 4.8。按作者的说明，如果主账号使用 Google、Facebook、X 等第三方登录，还需要提供等效的隐私友好选项：只收集姓名和邮箱，并允许用户隐藏邮箱。常见方案是 Sign in with Apple。

作者特别指出，AI builder 很喜欢直接加上「Continue with Google」。这个按钮方便完成演示，却可能让 iOS 应用多出一项审核义务。原文也列出例外：只使用自有账号系统。

账号创建之后，还有删除。

作者引用 Apple 的 5.1.1(v)：支持创建账号的应用，也必须在应用内提供账号删除。Google Play 则要求应用内删除路径，以及供用户提交删除请求的网页链接，并在 Data safety 表单中申报。

注册、登录和删除，应该一起进入账号功能的验收范围。

按原文的提醒，仅写一句「发邮件联系我们删除账号」不够。对于依赖 AI 生成代码的项目，尤其要检查删除入口背后是否有实际处理流程，而不是只有一个页面或按钮。

审核员进不去，功能再完整也没用

Apple 的 2.1 对应一个很实际的问题：审核员必须能够进入应用并验证功能。

作者要求提供可用的演示账号，同时保持后端服务运行。如果使用免费层的 Supabase/Firebase，就应检查审核期间服务是否可能暂停，以及 OTP 或邮箱验证是否会阻挡审核员。

这里的验收对象是整条访问链路：账号能登录，验证码能完成，后台能响应。开发者自己已经登录的设备，无法证明审核员第一次打开应用时也能顺利进入。

第五项是 Apple 的 5.1.1(i)，以及 Google Play 的 Data safety。作者提醒，隐私政策需要同时出现在商店详情和应用内，隐私申报还要覆盖 SDK 收集的数据。

原文没有展开各类 SDK 的具体字段，也没有提供填写示例。可以带走的原则是：隐私答案要根据实际集成内容填写，不能只看业务页面上有没有向用户索取信息。

我的判断

这份清单最有用的地方，是把「功能完成」推进到「可以被审核」。账号删除、演示账号和 SDK 数据披露，都容易在赶演示时被遗漏，也都适合在提交前逐项检查。

但它仍是一份经验清单。作者没有交代样本数量、具体拒审案例或修改前后的结果，不能据此推算通过率。原文对 4.8 的说明也没有展开完整适用范围，不能当成覆盖所有应用的规则全文。

作者还在推广自己参与的 LetsDeployIt，服务范围包括将 Lovable、Bolt、Rork、FlutterFlow、RapidNative 生成的应用进行原生转换，处理商店资料、隐私表单和提交。这个商业背景不否定清单的价值，但「转成原生就能解决审核问题」仍需打个问号。

我的取舍是：把它用作提交前的排查入口。与上架前临时补材料相比，在生成账号和移动端功能时就纳入这些要求，更容易发现缺口。

能拿来做什么

• 给 AI 下达移动端开发任务时，把手机界面、离线处理和必要的设备能力写清楚，并单独检查 WebView 包装是否提供了足够的应用体验。
• 生成账号模块时，同时要求交付登录、隐私友好登录选项和账号删除流程；计划上 Google Play 的项目，再准备删除请求网页链接。
• 提交审核前，用演示账号从首次打开应用开始走一遍完整流程，检查 OTP、邮箱验证和后端服务状态。
• 根据项目实际集成的 SDK 整理数据收集情况，再填写隐私政策和 Data safety，核对商店详情与应用内入口是否齐全。