macOS 应用写完之后，怎么交到用户手里？

本文最后更新于 2026年10月10日下午

背景

第一次开发 Mac 应用，最容易困惑的地方，是代码写完之后。

在 Xcode 里点“运行”，应用已经能打开了。但准备交给别人时，又出现了签名、证书、公证、归档、商店审核这些词。

其实可以先抓住一条主线：

把代码变成应用 → 测试 → 选择分发渠道 → 完成渠道要求 → 让用户安装。

下面从头梳理，并说明每条路径分别怎么走。

一、先看完整地图

flowchart TD
    A["写好代码"] --> B["编译，生成 .app 应用"]
    B --> C["测试功能、权限和异常情况"]
    C --> D{"用户从哪里获得应用？"}

    D --> E["只在自己的 Mac 上使用"]
    E --> F["本地运行"]

    D --> G["官网、GitHub 或直接发安装包"]
    G --> H["Developer ID 签名"]
    H --> I["Apple 公证"]
    I --> J["附加票据、验证并打包"]
    J --> K["上传下载渠道"]
    K --> L["用户下载并安装"]

    D --> M["TestFlight 测试"]
    M --> N["上传 App Store Connect"]
    N --> O["配置测试与必要的测试审核"]
    O --> P["邀请用户试用并收集反馈"]

    D --> Q["Mac App Store 正式发布"]
    Q --> R["满足沙盒与商店要求"]
    R --> S["上传构建和商店资料"]
    S --> T["提交审核"]
    T --> U["通过后发布"]
    U --> V["用户从 App Store 安装"]

这几条路径不需要全部走一遍。你可以只给自己用，也可以只提供官网安装包，或者选择 App Store。

TestFlight 是测试渠道，通常服务于发布前的试用。

二、共同的起点：把代码变成应用

1. 写代码

源码里包含应用的功能、界面，以及图标等资源。

用户通常不会拿这些源码安装。他们需要的是编译好的应用。

2. 编译

Xcode 把源码转换成 macOS 可以运行的程序，最终形成：

1	`SSHGuard.app`

.app 看起来像一个文件，实际上是一个应用包，里面装着程序、资源和配置信息。

开发过程中，点击 Xcode 的“运行”，就会完成编译并启动应用，方便你边写边看效果。

3. 测试

编译成功，只说明程序可以被生成出来。

接下来要检查：

是否能启动，主要功能是否正常。
用户拒绝权限时，应用是否能正确处理。
保存、删除、恢复等操作是否安全。
退出再打开后，数据是否正常。
在支持的系统版本和设备上是否能运行。

这些工作不能由签名、公证或商店审核代替。

4. 准备发布构建和归档

准备交付时，通常会生成 Release 构建，再保存一份归档。

可以把归档理解为：把这次准备发布的版本完整留底。

flowchart LR
    A["源代码和资源"] -->|"编译"| B["可运行的 .app"]
    B -->|"归档"| C[".xcarchive<br/>保存发布构建"]
    C -->|"导出"| D["用于交付的应用"]

.xcarchive 给开发者保存和导出使用，普通用户不需要用它安装。

完成这些共同步骤之后，再按渠道继续。

三、路径一：只给自己用

如果只是给自己做一个小工具，流程很短：

flowchart LR
    A["写代码"] --> B["在 Xcode 编译运行"]
    B --> C["测试和修复"]
    C --> D["在自己的 Mac 上使用"]

你可以继续通过 Xcode 启动，也可以使用本地生成的应用。

在自己的开发机器上使用，不需要为了发布而提交 Apple 公证或商店审核。

但自己的电脑能运行，不代表发给别人就能顺利打开。另一台 Mac 会检查下载应用的来源，而且可能有不同的系统、权限和运行环境。

准备交给其他人时，就需要选择下面的分发方式。

四、路径二：官网、GitHub 或直接发安装包

用户从你的下载链接获得 ZIP 或 DMG，再将应用安装到自己的 Mac。

这是商店外直接分发。完整流程如下：

flowchart TD
    A["测试通过的发布构建"] --> B["使用 Developer ID 证书签名"]
    B --> C["上传 Apple 公证服务"]
    C --> D{"公证结果"}
    D -->|"未通过"| E["查看原因，修复后重新提交"]
    E --> B
    D -->|"通过"| F["获得公证票据"]
    F --> G["将票据附加到应用"]
    G --> H["验证签名、票据和系统接受状态"]
    H --> I["生成最终 ZIP 或 DMG"]
    I --> J["验证最终安装包"]
    J --> K["上传官网或 GitHub"]
    K --> L["用户下载、安装并打开"]

为了让商店外分发的应用在默认 Gatekeeper 安全设置下通过检查，需要使用 Developer ID 签名并完成公证。Apple 平台安全说明

第一步：签名——说明是谁发布的

签名可以理解为开发者给应用盖的一枚“可验证的印章”。

它帮助系统确认：

应用由哪个开发者签发。
签名之后，文件有没有被改动。

商店外分发的应用通常使用 Developer ID Application 证书签名。Apple 签名文档

证书背后还对应一个私钥。私钥用于执行签名，应妥善保存在本机或安全的构建环境中，不能当成普通文件发给别人。

第二步：公证——让 Apple 做自动安全检查

签名完成后，把应用提交到 Apple 公证服务。

Apple 会检查已知恶意内容，以及签名等必要条件。通过后，为这份软件签发公证票据。Apple 公证说明

这里要分清三件事：

公证不会替你验证所有功能，不会自动上架 App Store，也不会自动提供公开下载链接。

它只是这份软件的安全检查环节。

第三步：附加票据——让应用带着检查凭证

公证通过后，可以把票据附加到应用上，这一步叫 staple。

这样，用户的 Mac 在无法连接 Apple 服务时，也可以核验应用携带的公证凭证。

如果提交的是 ZIP，不能直接给 ZIP 附加票据。通常需要给里面的 .app 附加票据，再重新压缩。Apple 公证工作流

所以，最终发布包必须包含附加票据之后的应用。

第四步：验证和打包

发布前，要确认签名完整、公证票据有效，以及 Gatekeeper 接受应用。

Gatekeeper 就是 macOS 打开下载应用时进行安全检查的机制。即使应用已经公证，首次打开时仍可能出现正常的“是否确定打开”提示。Apple 支持说明

用户下载的包装通常有三种：

格式	安装方式	常见用途
ZIP	解压，将应用拖进“应用程序”	简单工具、早期版本
DMG	打开磁盘映像，拖动应用安装	常见的 Mac 安装体验
PKG	跟随安装器完成步骤	需要安装多个组件的应用

它们是包装和安装方式，不是三个不同的发布渠道。涉及安装器或磁盘映像时，还需要按对应格式处理签名和公证。Apple 打包文档

第五步：放到用户能下载的地方

官网、GitHub Releases、直接发文件，都可以交付同一份安装包。

下载渠道	适合什么情况	你要负责什么
官网	产品介绍、帮助、购买和下载集中展示	网站、文件托管、版本说明
GitHub Releases	按版本提供安装包	发布文件、更新说明
直接发文件	少量用户试用	说明版本、安装方式、收集反馈

它们都不会自动为你的应用增加更新功能。初期可以让用户手动下载新版本；应用内自动更新需要另外实现。

下面这张图说明了两次“上传”的区别：

sequenceDiagram
    participant D as 开发者
    participant A as Apple 公证服务
    participant W as 官网或 GitHub
    participant U as 用户

    D->>D: 构建、测试并签名
    D->>A: 上传应用，申请公证
    A-->>D: 通过后提供公证票据
    D->>D: 附加票据，验证并打包
    D->>W: 上传最终安装包
    U->>W: 下载
    U->>U: 安装并打开应用

上传 Apple 是为了检查；上传下载渠道是为了交付。

五、路径三：Mac App Store

如果希望用户在 App Store 搜索、安装和更新应用，就走商店流程。

flowchart TD
    A["检查功能能否符合沙盒和商店要求"] --> B["准备并测试商店版本"]
    B --> C["创建 App Store Connect 应用记录"]
    C --> D["准备介绍、截图、隐私信息等资料"]
    D --> E["上传构建"]
    E --> F["选择构建并提交审核"]
    F --> G{"审核结果"}
    G -->|"需要修改"| H["根据反馈调整应用或资料"]
    H --> F
    G -->|"通过"| I["按所选方式发布"]
    I --> J["用户从 App Store 安装"]
    J --> K["后续版本通过商店更新"]

先确认功能能否进入商店

Mac App Store 对应用有额外要求，其中包括 App Sandbox。

沙盒会限制应用可以访问的文件和系统资源。应用需要通过适当的授权和技术方案完成所需操作。Apple 沙盒文档

因此，需要访问用户文件、运行工具或与其他应用协作的软件，应提前验证这些功能能否符合要求。不能等全部做完后，才发现核心功能需要调整。

再准备商店页面和构建

App Store Connect 是开发者管理商店应用的后台。

你需要建立应用记录，准备介绍、截图和隐私信息，并上传适合商店分发的构建。

上传成功只是材料到了后台，还没有上架。

之后要提交审核。审核通过，再按选择的发布方式让用户获得应用。

商店版本也要遵守对应的更新规则。Apple 审核指南

商店审核和公证不是一回事

对比项	商店外公证	App Store 审核
主要用途	自动安全检查	检查是否符合商店要求
通过后由谁分发	开发者安排下载渠道	App Store
是否创建商店页面	不会	发布后有
是否替代开发者测试	不会	不会

通过 Mac App Store 分发的应用，不需要再单独完成商店外的 Developer ID 公证流程，商店提交过程包含相应安全检查。Apple 公证说明

六、TestFlight：正式发布前先邀请用户试用

如果还没准备正式发布，希望先收集反馈，可以使用 TestFlight。

flowchart TD
    A["准备测试构建"] --> B["上传 App Store Connect"]
    B --> C["配置测试信息和测试人员"]
    C --> D["外部测试按要求完成测试审核"]
    D --> E["用户通过 TestFlight 安装"]
    E --> F["收集反馈"]
    F --> G["修改并上传新构建"]
    G --> C

TestFlight 提供测试版的安装和反馈渠道。每个构建最多可测试 90 天，外部测试构建可能需要审核，因此不适合作为永久正式安装包。Apple TestFlight 说明

少量用户试用也可以直接领取公证安装包，不一定要使用 TestFlight。

七、每次更新，都要重新走哪些步骤？

发布不是只做一次。

假设第一版是 1.0，后来修复问题，准备发布 1.1：

flowchart TD
    A["修改代码，准备新版本"] --> B["重新构建和测试"]
    B --> C{"使用哪个渠道？"}
    C --> D["直接分发"]
    D --> E["重新签名、公证、打包和验证"]
    E --> F["发布新安装包，通知或提供更新"]

    C --> G["App Store"]
    G --> H["上传新构建，提交新版本审核"]
    H --> I["通过后发布更新"]

    C --> J["TestFlight"]
    J --> K["上传新测试构建并安排测试"]

上一版的签名和公证，不能直接代替修改后新版本的发布检查。

八、最后还要模拟一次用户安装

无论选择什么渠道，都应该测试用户真正拿到的版本。

从最终下载链接或测试渠道安装，检查首次启动、权限请求和关键功能，不能只测试 Xcode 里的开发构建。

对于会修改重要文件的软件，使用专用测试账户、独立测试数据或可回滚环境。

例如 SSH 管理工具，不应拿日常使用的密钥和配置去做破坏性恢复测试。

九、SSHGuard 当前走的是哪条路？

SSHGuard 当前选择的是商店外直接分发。

因为它需要管理真实的 ~/.ssh、使用系统 SSH 并与终端协作，先沿这条路径完成交付。以后是否上 App Store，再单独评估沙盒和商店要求。

当前进度如下：

flowchart TD
    A["构建与归档：已完成"] --> B["Developer ID 签名：已完成"]
    B --> C["Apple 公证：尚未提交，已暂停"]
    C --> D["附加票据、最终打包与验证：待完成"]
    D --> E["真实安装和功能验收：待完成"]
    E --> F["上传下载渠道：待完成"]

    style A fill:#dcfce7,stroke:#16a34a,color:#14532d
    style B fill:#dcfce7,stroke:#16a34a,color:#14532d
    style C fill:#fef3c7,stroke:#d97706,color:#78350f