原生应用与渐进式 Web 应用：你需要哪一种？

原生应用专为 iOS 或 Android 构建，从 App Store 或 Google Play 安装。**渐进式 Web 应用（PWA）**则是一个可以安装到手机主屏幕、并以自己的全屏窗口和图标打开的网站，无需经过任何应用商店。原生应用能获得最深入的设备访问权限；PWA 则通过一套代码和一个链接覆盖所有平台，并且能即时更新。

对于大多数第一版产品来说（工具、门户、追踪器、预订和点餐应用），PWA 已经足够。只有当应用商店的发现渠道或深度设备功能是产品的核心时，才需要原生应用。

用 AI 开发时，为什么这一点很重要

大多数 AI 应用构建工具生成的都是 Web 应用。这不是什么捷径，而是这些工具的强项，因为 Web 应用可以在同一个地方编写、预览和发布。但这也意味着，“它会成为我手机上的应用吗？”这个问题有一个明确的答案：它会是一个表现得像应用的网站，如果你提出要求，它可以被安装为 PWA。

了解 PWA 能做什么、不能做什么，能让你尽早做出决定，免得你在向客户承诺“它会上架 App Store”之后才发现问题，也免得你设计出一个 Web 无法可靠实现的功能（比如后台位置追踪）。

一个日常类比：餐车与商场里的店铺

原生应用就像商场里的一家店铺。商场（应用商店）能带来人流和信任，但你要交租金、遵守商场的规则，而且在改变店面门头之前还要等待审批。

PWA 则像一辆拥有忠实食客的餐车。没有房东，你今晚就能换菜单，认识你的人在任何地方都能找到你。但商场走廊里不会有人路过你的车，你也没法装一个入墙式冷库。

能做什么对比

表格中的几个术语：

• Service Worker： 浏览器在后台为你的网站运行的一小段脚本。它让应用可以离线打开、缓存数据并接收推送消息。
• Web 应用清单（Manifest）： 一个小文件，告诉浏览器应用的名称、图标、配色，以及它应当以全屏（“standalone”）而非浏览器标签页的方式打开。

iPhone 和 iPad：容易踩坑的细节

苹果的平台是 PWA 与原生应用差异最大的地方，所以需要说得精确一些。根据苹果 WebKit 团队和 Google 的 web.dev，截至 2026 年 9 月的情况如下：

• 安装需要手动操作。 Chrome 等 Android 浏览器可以弹出安装提示。而 iPhone 和 iPad 没有自动提示，用户需要点击分享，再点击添加到主屏幕。自 iOS 16.4 起，iOS 上的其他浏览器也能在分享菜单中提供“添加到主屏幕”。
• 在 iOS 26 中，添加到主屏幕的每个网站默认都以网页应用的形式打开。 WebKit 宣布，从 iOS 和 iPadOS 26 起，添加到主屏幕的任何内容都会在自己的窗口中打开，除非用户关闭“以网页应用打开”。正确的 Manifest 对于应用名称、图标和行为依然重要。
• 推送通知需要先安装。 网页推送自 iOS 和 iPadOS 16.4 起支持主屏幕上的网页应用。在 Safari 标签页中打开的 PWA 无法接收推送；用户必须先安装，再允许通知，而且权限请求必须在点击某个按钮（例如“开启通知”）之后出现。图标上的角标计数也是同时推出的。
• 深层硬件访问非常有限。 一些 Android 浏览器支持的蓝牙配件和 NFC 等功能，Safari 并不提供。

实际结论是：如果你的整个产品都依赖通过通知提醒用户，那么许多从未安装应用的 iPhone 用户将永远收不到这些通知。请规划一个邮件或短信的备用方案。

进入应用商店

如果你确实需要上架商店，请提前了解成本和规则。截至 2026 年 9 月，据苹果和 Google 各自的官网，苹果开发者计划每年 99 美元，Google Play 开发者账号一次性 25 美元。每一次 iOS 发布都要经过 App Review。苹果的指南要求应用提供超出简单打包网站的功能和界面，因此把 PWA 包进一层薄薄的原生外壳，有被拒的风险。

实例：一家健身房的会员应用

一家小型健身房希望会员能够预约课程、查看会员资格，并在课程开始前一小时收到提醒。

PWA 方案。 构建一个响应式网页应用，包含登录、课程表和预约功能。添加 Manifest 和图标，让会员可以安装；再添加 Service Worker，使课程表即使在信号很差时也能打开。向已安装的用户发送推送提醒，向其他人发送邮件提醒。应用只需上线一次，就能在每部手机和电脑上运行，健身房也能当天就调整课程表的布局。

什么时候原生方案更合适。 如果健身房之后希望加入在门口使用蓝牙信标的签到功能、接入 Apple Health 记录训练数据，或者在锁屏上显示当天课程的小组件，那么这些都属于原生的领域。如果会员期望在应用商店中搜索“健身房应用”就能找到它，也同样属于原生的范围。

很多团队就是这样做的：先用 PWA 验证会员是否真的在用，之后如果某项特定功能或商店曝光值得投入成本，再做原生版本。

常见误区

• “PWA 是低配的应用。” 对于表单、列表、预订、仪表盘和内容类应用，安装之后，用户往往分不出区别。
• “PWA 在 iPhone 上用不了。” 可以用。限制在于安装门槛高，以及推送通知必须先安装，而不在于基本功能。
• 以为推送能送达每个人。 在 iPhone 上，推送只会送达那些安装了应用并同意接收的人。
• 承诺自己无法交付的 App Store 应用。 在承诺上架之前，先确认你的构建工具究竟能生成什么。
• 构建自己并不需要的离线编辑功能。 缓存页面以便离线打开很简单；离线编辑数据并稍后同步则是实打实的工作量。

向你的 AI 构建工具提出什么要求

如果要做 PWA，请把要求说清楚：

• “把它做成可安装的 PWA：包含 Web 应用清单，设置名称、短名称、图标（包括 Apple touch 图标）以及 standalone 显示模式。”
• “添加一个 Service Worker，缓存应用的基础框架，让它在没有网络时也能打开，并显示清晰的离线提示。”
• “添加一个“安装此应用”的帮助页面，分别提供 Android 和 iPhone 的步骤（点击分享，然后选择“添加到主屏幕”）。”
• “如果我们加入通知功能，只在用户点击按钮之后再请求权限，并提供邮件作为备用方案。”

构建移动端友好 Web 应用的指南提供了完整的提示词和手机优先设计清单。如果你还在决定第一版应该包含什么，可以阅读什么是 MVP；如需预算对比，请参阅开发一款应用要花多少钱。

PWA 与 Mythex

Mythex 构建的是 Web 应用，你可以在发布前用手机尺寸的预览检查每一个界面。PWA 的 Manifest、图标和 Service Worker，和其他功能一样，只需在对话中提出要求即可。发布后的应用通过一个链接即可在任何手机上使用。在 Pro 方案中，Mythex 还可以使用 Capacitor 将 Web 应用封装为 Android 和 iPhone 应用，并提交到 Google Play 内部测试和 TestFlight：这是一种混合应用，其界面是 Web 界面，而非完全原生的 UI。要开始，可以浏览应用模板或AI Web 应用构建器。

常见问题