如果你已经有 Web 应用，「做成 Mac 应用」可以指很不同的事：

• 像应用一样打开的网站（Dock 图标、独立窗口）
• 可分发给用户的 .app
• 具备系统级集成的桌面产品（文件系统、通知、深度链接、自动更新）

下面是目前常见的实践路径—从最简单到最接近「真正应用」的顺序。

---

1) Safari 网页应用（添加到程序坞）：最快的「像应用」Mac 存在感

从 macOS Sonoma 起，Safari 可以把网站保存为独立网页应用，出现在程序坞中，并独立于 Safari 运行。 Apple 支持

适合何时使用

• 想要几乎零成本的轻量桌面存在感。
• 你的 Web 应用在桌面 Safari 上已经运行良好。

如实说明限制

• 不等于你在分发打包好的产品，主要是用户侧的「安装」体验。
• 与真正应用相比，原生集成很有限。

---

2) 桌面 PWA：跨平台的「可安装网页应用」（有前提）

渐进式 Web 应用（PWA）通过 manifest 和 service worker，在支持的浏览器上实现可安装性和偏离线的体验。 Apple 支持

适合何时使用

• 想保持 Web 优先，避免应用打包和原生构建流水线。
• 应用主要是表单、仪表盘、内容或内部工具。

缺点

• 桌面「安装」行为因浏览器和系统而异，体验可能不一致。

---

3) Electron：把 Web UI 做成真正 Mac 应用的主流方案

Electron 是常见的「用 Web 技术做桌面应用」方案：用桌面运行时打包你的 UI，通过 Electron 环境和 Node 访问系统能力。Electron 官方文档将其定位为带教程、最佳实践和架构指南的完整框架。 electronjs.org

适合何时使用

• 需要真正可分发的应用（DMG、公证流程等）。
• 希望 Web 功能兼容性最好（因为自带 Chromium）。
• 想要成熟生态和大量示例。

代价（直说）

• 体积大。会打包浏览器运行时，即使简单应用也可能显得「笨重」。

---

4) Tauri：思路类似 Electron，用系统 Web 渲染器更轻量

Tauri 通过使用系统原生 Web 渲染器来缩小体积，同时可以保留任意前端技术栈，用 Rust 写后端。 Tauri

适合何时使用

• 喜欢 Electron 的开发模式，但希望应用更小、设计更注重安全。
• 能接受「桌面应用」里加入一些 Rust/后端思维。

现实

• 根据需求，可能比 Electron 更早接触偏原生的工具链。

---

5) Neutralinojs：超轻量「Web 转桌面」封装

Neutralinojs 主打轻量、可移植，用 HTML/CSS/JS 做桌面应用，通过 IPC 扩展增强功能。 Neutralinojs

适合何时使用

• 觉得 Electron 像用大炮打蚊子。
• 应用简单，希望开销尽量小。

缺点

• 生态比 Electron 小。若需要非常规系统集成，需要更多自己动手。

---

6) 自建原生 macOS 壳（WKWebView）：控制最大，责任也最大

可以用 Swift/SwiftUI/AppKit 写原生 macOS 应用，在 WebView 里加载你的 Web 应用，并自己实现 JS↔原生桥接。这样 macOS 集成最干净，但所有边界情况都要自己负责。

适合何时使用

• 需要紧密的 macOS 行为（自定义菜单、深度集成、严格安全策略）。
• 想完全掌控更新、权限和应用生命周期。

缺点

• 「简单」只维持到功能需求增多之前，之后就是在 WebView 里嵌 Web UI 的原生开发。

---

该选哪一个？

简单直接的选择指南：

选 Safari 网页应用 / PWA 当…

• 主要只想「像应用一样打开」，产品本质是网站。 Apple 支持

选 Electron 当…

• 想要把 Web 渲染行为意外降到最低、最成熟的桌面产品分发路径。 electronjs.org

选 Tauri 当…

• 想要桌面产品，但很在意体积和利用系统 Web 渲染器。 Tauri

选 Neutralinojs 当…

• 应用简单，想要最轻、仍有桌面应用感的封装。 Neutralinojs

选自建 WKWebView 壳当…

• macOS 专属集成本身就是目标，且愿意维护原生代码库。

---

容易浪费数月时间的常见错误

• 把「窗口里的 Web 应用」当成完整产品。 分发、更新、权限、深度链接、安全策略都很重要。
• 忽视自动更新策略。 一旦分发桌面应用，就需要在不折腾用户的前提下更新它的方案。
• 低估「桌面 UX」。 菜单、快捷键、窗口行为、拖放、文件处理—用户期待桌面级标准。