Sparkle：macOS 的软件更新框架

原文 ↗ Hacker News 讨论 ↗

Sparkle 是一个流行的开源 macOS 软件更新框架，因其能为第三方应用提供一种一致、低摩擦的方式来在 Mac App Store 之外交付更新而广受好评。评论者将其可预测的 UX 和基于 S3 的简单分发方式，与 Windows 上常见的碎片化或笨重做法进行对比，并提到 WinSparkle、Squirrel 和 Homebrew 等相关工具。讨论还涉及隐私与“回传”、沙盒与 App Store 的限制，以及即使包管理器和替代应用商店越来越受关注，Sparkle 之类的工具仍然很重要。

Sparkle 的整体看法

  • 它被广泛视为 macOS 应用自更新的事实标准；许多人认为其他替代方案明显更差。
  • 长期开发者表示，自己用了十多年、完成了数百万次更新，几乎没有问题。
  • 用户明确表示喜欢在不同应用中识别 Sparkle 对话框；这种一致性建立了信任和舒适感。

用户体验：对话框、通知和时机

  • 一些用户喜欢“有可用更新”的弹窗并阅读更新日志；另一些人觉得这种模态对话框很烦，尤其是在打字时被打断。
  • 主要投诉集中在 Sparkle 没有把 macOS 通知中心作为主要展示界面，也没有以可预测的方式尊重“勿扰模式”。
  • 维护者（按线程中的引用）指出，DND 和通知中心很难在通用框架中可靠集成；较新的 Sparkle 版本支持“温和提醒”，以及可选的自动下载/自动安装，以减少打扰。

Windows 和跨平台对应方案

  • 评论者对 Windows 应用每次更新都强制手动访问下载页并运行完整安装程序表示遗憾。
  • 线程中提到了 WinSparkle、Squirrel、MSIX + 计划任务，以及跨平台的 .NET/NetSparkle 这类类似 Sparkle 的方案，但它们似乎利用不足。
  • 一些开发者即使在 macOS 上使用 Sparkle，仍然会为 Windows 自己编写逻辑（例如 MSI 下载器）。

macOS 应用分发 vs 包管理器

  • 除了 Mac App Store 之外，macOS 缺少面向 GUI 应用的系统级包管理器；Sparkle 为自分发应用以及那些无法被沙盒化的应用填补了这一空白。
  • Homebrew（含 cask）和 MacPorts 被大量讨论，作为 CLI 工具和 GUI 应用的并行生态。
  • 关于 Homebrew 与 MacPorts 的取舍（文件系统布局、可靠性、权限）存在争论，但许多高级用户仍依赖 brew upgrade 来完成大多数更新。
  • Sparkle feed 有时也被 Homebrew 用作 livecheck 来源。

隐私、安全与“回传”

  • 有些人担心类 Sparkle 框架会让每个应用都联系服务器；也有人回应说，任何更新系统（商店、包管理器、自定义方案）都必须这样做。
  • Sparkle 检查是周期性的（通常最多每 24 小时一次），通常只是获取一个很小的 XML/RSS “appcast”。
  • 安全方面的担忧主要集中在更新服务器被攻破，而不是 Sparkle 本身；线程中提到过一起通过被黑下载服务器传播恶意软件的事件。

相关工具与生态怀旧

  • 类似 Latest.app 的工具会聚合使用 Sparkle 的应用并显示待更新项。
  • 该线程还带有对更早期 Mac 应用和框架的怀旧（例如经典 IM 客户端、Growl），以及对更一致的原生软件 UX 的怀念，而 Sparkle 正是其中仍然保留的一部分。