如何将 Lovable 应用发布到 App Store：PWA、Capacitor 与原生重写对比，以及如何避免 4.2 被拒（2026）

如果你正在搜索如何把 Lovable 应用发布到 App Store，首先要知道：Lovable 无法替你完成这件事。Lovable 发布文档写道：“Lovable 构建的是网页应用，发布始终部署到一个网页 URL”，并且“没有将你的项目打包并提交到 App Store 或 Google Play 的内置流程”。下面介绍三种可行方案、各自的成本，以及让套壳后的 Lovable 应用避开审核指南 4.2 的具体步骤。

Lovable 应用能直接发布到 App Store 吗？

不能。截至 2026 年 10 月，Lovable 只能发布到 lovable.app 子域名或自定义域名；要进入应用商店，必须在 Lovable 之外打包应用，并用你自己的开发者账号提交。

Lovable 文档给出了两种变通方案：把已发布的网站做成可安装的 PWA，或者“在 Lovable 之外用 Capacitor 将你的已发布 URL 封装进原生外壳”，然后自行提交这个外壳应用。文档还明确了两点：Lovable 不会生成 React Native 项目；Lovable 手机应用只是用来在手机上构建项目，它“不会把你的项目变成面向最终用户的原生应用”。

PWA、Capacitor 套壳还是原生重写：该选哪条路线？

如果不需要商店上架，选 PWA；如果需要上架且能加入真正的原生功能，选 Capacitor；如果你的应用必须像以手机为核心的产品那样运行和交互，就选择原生重写。

费用信息来自 Apple Developer Program 注册页面（“每个会员年度 99 USD，价格可能因地区而异”）和 Google Play 管理中心帮助（“一次性 US$25 注册费”）。在 Google Play 上，新的个人账号还必须先进行 12 名测试人员、持续 14 天的封闭测试，才能获得正式版发布权限。我们的封闭测试指南详细介绍了这一步。

如何用 Capacitor 封装 Lovable 应用？

把 Lovable 代码导出到 GitHub，在本地构建，添加 Capacitor 并把 webDir 指向构建输出目录。然后在 Xcode 和 Android Studio 中打开原生项目并归档。

1. 在 Lovable 中连接 GitHub。同步是双向的，并且总会创建一个新的私有仓库，因此你可以一边继续在 Lovable 中编辑，一边在本地开发原生外壳。
2. 克隆仓库，运行 npm install，然后运行 npm run build。确认 Vite 的输出目录，通常是 dist。Capacitor 要求该目录根部有一个包含 <head> 标签的 index.html。
3. 使用下方代码块中的命令安装 Capacitor 及各平台，命令来自 Capacitor 入门文档。
4. 在 capacitor.config 中将 webDir 设为 dist。不要把 server.url 设为你线上的 Lovable 域名：Capacitor 配置参考指出它“不适用于生产环境”。
5. 添加原生插件（推送、触感反馈、分享、生物识别、本地通知），以及原生应用图标和启动画面。
6. 每次网页构建后运行 npx cap sync，然后在 Xcode 中归档并上传到 App Store Connect。其余步骤见我们的 App Store 提交检查清单。

npm i @capacitor/core
npm i -D @capacitor/cli
npx cap init
npm i @capacitor/android @capacitor/ios
npx cap add android
npx cap add ios
npm run build && npx cap sync
npx cap open ios

请用你自己的 Apple 账号提交。审核指南 4.2.6 会拒绝由应用生成服务创建的应用，除非它们“由应用内容的提供者直接提交”。我们的审核指南 4.3 与 4.2.6 指南解释了这条规则如何适用于 AI 构建的应用。

套壳的 Lovable 应用如何避免因审核指南 4.2 被拒？

让应用做到网站做不到的事。审核指南 4.2 要求应用具备“让其超越重新包装的网站的功能、内容和 UI”，而 4.2.2 则排除了主要由“网页剪辑、内容聚合或链接集合”构成的应用。

提交前请对照以下清单检查：

• 网页构建产物已打包进二进制文件，断网时也能打开，并显示缓存数据或合适的离线页面。
• 导航使用底部标签栏而不是汉堡菜单，且没有仅属于网页的页脚或 Cookie 横幅。
• 登录、注册和重置密码都在应用内完成，不会把用户跳转到 Safari。
• 至少有一项核心流程依赖设备能力，例如相机拍摄、与用户自身数据关联的本地通知、小组件或生物识别。
• 指向捐赠页面、商店或社交媒体的外部链接已删除或尽量减少。
• App 审核备注说明了该应用在手机上为何有用，并附上演示账号。

其他基于网页的应用因 4.2 被拒后发生了什么？

公开讨论帖呈现出相同的模式：审核人员会拒绝有网页感的 UI 和跳转到 Safari 的链接，而仅仅添加少量原生功能并不能改变他们的决定。

2020 年 12 月，Ionic 论坛上一位开发者的俱乐部会员应用被拒，理由是“你的应用提供的用户体验有限，因为它与移动浏览器体验没有足够区别”，随后又指出“应用的大部分内容都跳转到 Safari”。移除 InAppBrowser 并改进离线支持后仍然不够，第二次提交同样被拒。第三次提交获得通过：开发者用原生风格的列表和图片卡片重建了首页，增加了更多应用内新闻内容，并删除了大部分外部链接。

2026 年 1 月，Apple 开发者论坛上一位开发者反馈，其日程安排应用被认定“与网页浏览体验没有足够区别”而被拒，尽管它已经使用了推送通知、Core Location 和通讯录访问。该开发者计划添加触感反馈、快捷操作和更深入的日历集成，并询问怎样才算“更原生”。截至本文撰写时，该帖子没有回复，也没有确认的结果。

对比来看：第一位开发者通过改变应用本身（应用内内容、原生布局、不再外链）获得通过；第二位只添加了设备 API，仍然不确定能否通过。请把精力放在核心体验上，而不是罗列更多权限。

什么时候应该原生重写，而不是套壳？

如果应用的主要价值就是网页内容，或者你已经因同一套 UI 被 4.2 拒绝过两次，就应该进行原生重写。

实例：一个为瑜伽馆做的 Lovable 预约工具，包含课程列表、预约表单和一个 Stripe 结账链接。如果原样套壳，它会同时触发 4.2 的三个危险信号：网页 UI、外部链接、无法离线使用。作为 PWA，它今天就能上线，且没有额外费用。若要在商店上架，可以保留 Lovable 后端，用原生页面重建课程列表和预约流程，在每节课前添加本地提醒，并按照 App 审核指南 3.1 的规则处理支付。你的后端和数据模型都可以沿用，需要重写的是 UI。

如果你想就哪条路线适合你的 Lovable 项目听听其他意见，The App Guy 的服务涵盖套壳、重写和商店提交，也可以发邮件至 yagyeshsrbobde@gmail.com。