macOS App 发布怎么选

你写完了一个 macOS App，打包发给朋友，对方双击后却看到“无法验证开发者”“App 已损坏”，甚至根本打不开。

这时很容易冒出一连串问题：

• 我是不是必须每年花 688 元加入 Apple Developer Program？
• 不交钱，能不能把 App 放到 GitHub 给别人下载？
• 签名、公证、Gatekeeper 到底是什么？
• 为什么有些开源软件会让用户复制一条命令才能打开？
• 通过苹果公证，是不是就等于上架了 Mac App Store？

先说结论：不是每个 macOS App 都需要上架商店，也不是每个小工具一开始都值得购买开发者会员。 你真正要选的，是下面三条发布路线中的一条。

先看简短回答

1. 只是偶尔做个小工具，用户也懂技术：走免费发布路线，把安装包放到 GitHub，用户第一次安装时手动放行。
2. 准备认真维护，但不需要上架商店：购买 Apple Developer Program，用 Developer ID 签名并公证。这是大多数独立 macOS App 最合适的正式发布方式。
3. 要做正规商业产品，希望通过商店搜索、购买和更新：提交 Mac App Store，同时接受沙盒和审核规则。

三条路线怎么选

flowchart TD
    A["macOS App 已经构建完成"] --> B{"准备怎么发给用户？"}
    B -->|"少量分享，用户懂技术"| C["路线一：免费发布"]
    B -->|"GitHub 或官网公开下载"| D["路线二：Developer ID 正式发布"]
    B -->|"通过苹果商店分发"| E["路线三：Mac App Store"]

    C --> C1["打包 ZIP 或 DMG"]
    C1 --> C2["用户手动绕过 Gatekeeper"]

    D --> D1["Developer ID 签名"]
    D1 --> D2["苹果公证并装订票据"]
    D2 --> D3["官网或 GitHub 下载"]

    E --> E1["App Store 签名与沙盒"]
    E1 --> E2["上传 App Store Connect"]
    E2 --> E3["提交审核并由商店分发"]

如果你现在仍然拿不准，可以先问自己一个问题：用户愿不愿意为了安装你的 App，理解并执行一次安全放行操作？

愿意，就可以从路线一开始。不愿意，就应该选择路线二或路线三。

路线一：免费发布，用户手动放行

这条路线不需要付费开发者账号。开发者构建 App 后，将 .app 打包成 ZIP 或 DMG，放到 GitHub Releases、网盘或自己的网站上。

因为这个 App 没有经过 Apple 认可的 Developer ID 签名和公证，用户从浏览器下载后，macOS 的 Gatekeeper 通常会拦截它。

用户有两种常见的放行方法。

方法一：在系统设置里仍要打开

先尝试打开一次 App，然后进入：

系统设置 → 隐私与安全性 → 安全性 → 仍要打开

这是 Apple 官方提供的单个 App 放行方法，比永久关闭系统安全检查更稳妥。

方法二：移除下载隔离标记

有些开源项目会让用户执行类似命令：

xattr -dr com.apple.quarantine "/Applications/Example.app"

浏览器下载文件时，macOS 会添加一个 com.apple.quarantine 隔离属性。上面的命令只是在用户明确相信这个 App 的前提下，移除该 App 的隔离标记。

它不会给 App 补上签名，不会完成苹果公证，也不能证明软件安全。它只是让 Gatekeeper 不再按“刚从互联网下载的未知软件”处理这一份文件。

这条路线省掉了什么

从开发者流程看，它省掉了这些步骤：

• 不用购买 Apple Developer Program
• 不用申请 Developer ID Application 证书
• 不用启用 Hardened Runtime
• 不用提交 Apple 公证
• 不用把公证票据 staple 到 App 或 DMG

但这些工作并没有凭空消失，而是变成了用户的安装成本和信任成本。

用户需要自己判断软件是否可信、自己处理安全警告。涉及辅助功能、输入监听、屏幕录制等敏感权限时，应用身份不稳定还可能导致升级后重新授权。自动更新也更难做得让人放心。

适合什么人

这条路线适合：

• 一年只做一两个小工具的业余开发者
• 只给自己、同事或少量朋友使用
• 用户本身就是程序员，能理解命令的含义
• 项目还在验证阶段，不确定会不会长期维护
• 开源项目能让用户检查代码和构建来源

如果你的 App 要求普通用户打开终端复制命令，或者还要申请辅助功能、输入监听等高敏感权限，用户很容易在第一步就放弃。到了这个阶段，继续省会员费通常不划算。

路线二：Developer ID 签名与公证

这是“不上 Mac App Store，但想让用户正常下载安装”的路线，也是我最推荐给认真维护项目的独立开发者的方案。

你需要加入 Apple Developer Program，然后用 Developer ID Application 证书给 App 签名。构建完成后，把 App 或安装包提交给 Apple 做自动化安全检查，也就是公证。公证通过后，再把票据装订到发布包中。

完整流程如下：

flowchart LR
    A["固定 Bundle ID"] --> B["Developer ID 签名"]
    B --> C["开启 Hardened Runtime"]
    C --> D["提交 Apple 公证"]
    D --> E["Staple 公证票据"]
    E --> F["制作 ZIP 或 DMG"]
    F --> G["发布到 GitHub 或官网"]

用户第一次打开时，macOS 仍可能显示“这是从互联网下载的 App，是否打开”，但这属于正常确认，不再是“无法验证开发者”或要求复制命令。

这条路线为什么适合独立开发者

• 下载入口仍然由你控制，可以放在 GitHub 或官网
• 不需要等待 App Store 审核每一个版本
• 不必为了上架而强行适配 App Sandbox
• 可以自己设计授权、付费和自动更新方式
• 用户安装门槛明显低于免费路线
• Developer ID 提供了稳定的开发者身份，更有利于系统权限和升级连续性

像输入法切换、剪贴板增强、菜单栏工具、窗口管理这类系统工具，往往需要全局快捷键、辅助功能或输入监听权限。它们不一定适合 App Store 的沙盒限制，却很适合用 Developer ID 公证后在站外分发。

怎么让后续版本被识别为同一个 App

macOS 并不是只看 App 名称和图标。为了让升级、自动更新和隐私权限尽可能连续，至少要长期保持下面这些身份信息一致：

证书到期或轮换并不等于 App 变成另一个程序。只要仍由同一个 Team ID 以正确方式签名，Bundle ID 和指定要求保持兼容，系统通常能维持同一个 App 身份。

不过，辅助功能、输入监听、屏幕录制这些权限属于 macOS 的 TCC 隐私系统。签名稳定能显著减少重复授权，但无法承诺用户永远不会再次看到授权请求。安装路径变化、Bundle ID 变化、签名链变化或系统升级都可能触发重新判断。

如果你正在实际配置证书、Tauri 或权限，可以继续看 macOS 签名与权限 和 Apple 开发者账号注册。

路线三：正式上架 Mac App Store

这条路线同样需要 Apple Developer Program，但它不是在路线二后面多点一下“上架”。两者是不同的分发体系。

Developer ID 版本是开发者自己分发；Mac App Store 版本则需要使用商店分发签名、配置 App Sandbox、上传到 App Store Connect，填写商店资料和隐私信息，再提交 Apple 审核。

flowchart LR
    A["创建 App Store Connect 记录"] --> B["配置 Bundle ID 与能力"]
    B --> C["启用 App Sandbox"]
    C --> D["归档并上传构建"]
    D --> E["填写截图、介绍和隐私信息"]
    E --> F["提交 App Review"]
    F --> G["审核通过后由商店分发"]

Mac App Store 构建不需要再按站外发布的方式，单独用 Developer ID 走一遍手工公证流程。构建上传后，由 App Store 的处理、签名和审核体系负责商店分发。

这条路线多了什么

• 用户可以在 Mac App Store 搜索、安装和更新
• 可以使用苹果的付费下载和应用内购买体系
• 商店页面提供更统一的品牌展示和信任背书
• 用户不需要判断 GitHub、DMG 和下载站是否可信

代价也很明确：

• 每个版本需要遵循审核流程
• 必须符合 App Store Review Guidelines
• 通常需要启用 App Sandbox，并只申请必要能力
• 商店资料、隐私申报、截图和版本状态都需要维护
• 某些依赖底层系统控制的工具，可能很难在沙盒中实现完整功能

如果产品严重依赖辅助功能、全局事件监听、进程控制或修改其他 App 的行为，先验证沙盒方案，再决定是否投入上架。不要等产品全部写完，才发现核心能力无法通过商店规则实现。

六个词一次讲明白

代码签名

可以把它理解成 App 的“身份证加防拆封条”。它告诉系统是谁发布了这个程序，以及签名后内容有没有被修改。

ad-hoc 签名只是一个临时封条，没有经过 Apple 认可的开发者身份。它能满足部分本机运行要求，但不能替代 Developer ID。

公证

公证是把已签名的 App 提交给 Apple 做自动化恶意软件检查。通过公证不代表 Apple 审核了产品质量，也不代表 App 已经上架商店。

Staple

公证通过后，Apple 会生成一张票据。Staple 就是把这张票据附到 App 或 DMG 上。这样用户离线安装时，系统也能验证公证结果。

Gatekeeper

Gatekeeper 是 macOS 门口的保安。它主要检查从互联网下载的软件来自哪里、签名是否有效、是否经过公证，以及内容有没有被篡改。

TCC 权限

TCC 管理麦克风、辅助功能、输入监听、屏幕录制等隐私权限。签名和公证让 App 有稳定身份，但不能替用户自动授予这些权限。用户第一次使用对应功能时，仍然需要明确同意。

App Review

App Review 是 Mac App Store 的上架审核。它会检查功能、内容、隐私、付费和平台规则。公证只是自动安全检查，App Review 才是商店准入审核，两者不是一回事。

三类开发者，我会这样推荐

偶尔做小工具的中小开发者

先走路线一。

你没有稳定收入，也不确定项目能不能活过三个月，完全没必要只为了“看起来正规”立刻交会员费。把来源、安装步骤和风险写清楚，只面向少量懂技术的用户，就够了。

等普通用户开始增多，安装问题反复占用支持时间，再升级到路线二。

认真维护小项目的独立开发者

选择路线二。

你不需要 App Store 的流量和支付，也不想受沙盒限制，但希望普通用户能放心安装，希望升级后权限尽量稳定，希望自动更新真正可用。Developer ID 签名加公证，通常是成本、自由度和用户体验之间最平衡的方案。

准备正规商业化的团队

评估路线三。

如果你看重商店搜索、统一购买、苹果支付体系和平台信任，愿意长期维护审核材料，也能在沙盒范围内完成核心功能，就值得上架 Mac App Store。

你也可以同时维护两种构建：一个 Mac App Store 版，一个 Developer ID 站外版。但它们的签名、能力、支付和更新体系不同，会明显增加测试与发布成本。

最后给一个简单判断

• 还在验证有没有人用：免费发布，别急着交钱。
• 已经有人用，而且安装说明越来越长：购买会员，做 Developer ID 签名与公证。
• 商店渠道本身就是商业计划的一部分：从一开始就按 Mac App Store 的沙盒和审核要求设计。

不要把“有没有上架 App Store”当作软件是否专业的唯一标准。很多优秀 macOS 工具都通过官网或 GitHub 直接分发。真正影响用户体验的，是发布者身份是否稳定、安装包能否验证、更新是否可靠，以及用户是否清楚自己正在授权什么。

官方资料

• Apple Developer Program 注册与费用
• Apple 开发者会员资格比较
• 创建 Developer ID 证书
• 对 macOS 软件进行公证
• Apple：安全地打开 Mac App
• 配置 macOS App Sandbox