做 macOS 应用时你可能遇到过一种很像“程序失忆”的现象：

• 阶段已经允许了辅助功能、屏幕录制或麦克风权限；
• 打包安装后应用又要求授权；
• 修改一次 Bundle ID，程序设置里原来的开关还在新版本却不能使用；
• 应用名称和图标明明没变，macOS 却像看到了一款全新的应用。

这并不是 macOS 单纯按应用名称识别软件，也不是每次打包都会随机生成一个神秘密钥。真正的原因是这方面，macOS 会结合 Bundle ID 和代码签名来判断“这是不是之前那一个应用”。当这个身份发生变化，旧权限不会自动转移给新身份。

还有 Electron 应用应该怎样配置，才能避免每次打包都重新授权。

先说文件名不是应用的身份证

假设桌面上有两个文件，都叫 Mimo.app图标也完全相同。按理说，对使用者它们看起来可能是同一个应用；对 macOS 来说却未必。按理说，

程序判断应用身份时关心的是这些信息：

1. Bundle ID
2. Team ID
3. Designated Requirement
4. 还会涉及应用方法、签名状态和权限类型。

可以把它粗略理解成：

这个类比不是完整的安全模型。但足以解释为什么“改个名字”通常没事，而“换 Bundle ID 或换签名”可能让权限全部失效。

Bundle ID、Team ID 和证书不是一回事

这几个概念经常被统称为“应用 ID”或“密钥”，结果越说越乱。它们承担的职责并不相同，

. Bundle ID：应用声明自己是谁

Bundle ID 通常采用反向域名格式：

com.example.mimo

它位于应用包的 Info.plist 中，对应 CFBundleIdentifier。在 Electron Builder 中，通常由 build.appId 决定。

Bundle ID 不是 Apple 随机发给你的秘密，也不是密码。你需要为应用选择一个长期稳定、在自己组织命名空间内唯一的字符串。使用推送、iCloud 等 Apple 能力时还要在 Apple Developer 后台注册相应 Identifier。

. Team ID：签名者属于哪个开发团队

Team ID 是 Apple 为开发者团队分配的标识。加入 Apple Developer Program 后可以在 Apple Developer 账户的 Membership 信息中查看。

再看例如，

A娱乐DE12345

同一个开发团队签发的证书通常会关联相同的 Team ID。它回答的是“这个应用由哪个 Apple 开发团队负责”，不是“这是哪个具体应用”。

. 签名证书：用来证明发布者身份

面向 App Store 外分发 macOS 应用时常用证书是：

Developer ID Application: Your Company Name

证书本身是公开身份信息与公钥； 真正需要妥善保管的是钥匙串中的私钥。 话说回来，打包工具使用私钥完成签名，其他人再用证书链验证签名是否可信。老实说，

平时所说的“签名证书”并不等于把某个密钥字符串填进配置文件。 老实说，私钥通常保存在 macOS 钥匙串中。CI 环境则通过加密的 .p12 文件和密码导入。不过，

. Designated Requirement：程序怎样 认出它

代码签名可以为应用形成一条指定要求。简化后它可能表达类似这样的条件：

identifier "com.example.mimo" and anchor apple generic and certificate leaf = "A娱乐DE12345"

Bundle ID 和签名团队会共同参与应用身份判断。

You can view a app's designated requirement with:

codesign -d -r- "/Applications/Mimo.app"> /dev/null

TCC 为什么会让旧权限失效

TCC管理 macOS 隐私权限，例如：

• 辅助功能;S屏幕与程序音频录制，M麦克风和摄像头;A自动化控制其他应用，说起来，C通讯录、日历、提醒事项等数据.

  User clicks “Allow” – system saves not just a simple “Allow Mimo.app”,but an authorization record that is tied to client’s identifying information . When app later requests a protected resource,TCC re‑evaluates wher requester still matches that identity.

  This leads to cases like:

  旧版本：com.example.mimo + Team A 的有效签名
  至于新版本，com.example.mimo.dev + Team A 的有效签名
  

  The Bundle ID changed,so macOS will not assume new binary inherits screen‑recording permission.

  A similar problem appears when Bundle ID stays same but signing identity changes:

  旧版本：com.example.mimo + Team A
  从新版本来看，com.example.mimo + 临时签名 或 Team B
  

  If signing team differs。old authorizations may no longer match.

  This security design prevents a malicious program from simply renaming itself “WeChat.app” and hijacking WeChat’s microphone or accessibility permissions.

  哪些操作容易让程序认为它是新应用

  修改 Bundle ID

  This is most direct identity change. For TCC y become two distinct clients:

  com.example.mimocom.example.mimo.desktop
  

  版和正式版使用不同 ID

  Certain projects deliberately separate environments:

  com.example.mimo.dev
  com.example.mimo
  

  This is fine – y should each have ir own permission set. Do not expect dev‑version authorizations to automatically flow into production.

  阶段没有稳定签名

  The local build might use ad‑hoc signing,an Apple Development certificate,or even be re‑signed by different tools;while release build uses a Developer ID Application certificate. The code requirements can differ.

  If you run your app directly from Electron/IDE during development,it’s actually Electron runtime that asks for permissions,not final signed .app bundle. Therefore a successful dev‑time grant does **not** guarantee that your distributed product already has those rights.

  CI 与本机使用了不同团队或证书

  If you switch teams or lose access to a private key 娱乐ween builds,resulting binary will present a different identity – causing TCC to treat it as brand new.

  打包后又修改应用内容

  If you replace Frameworks,Helpers or or resources after signing,you break signature. macOS may still launch but capabilities and authorizations can behave erratically.

  这些 ID 和证书到底去哪里获取

  . Bundle ID：由项目确定。需要时在开发者后台注册

  • Select a stable namespace,e.g.:

    com.yourcompany.product
    

  • If your app uses Apple services,go to: Apple Developer → Certificates,Identifiers & Profiles → Identifiers and create an App ID that matches your bundle identifier.

  . Team ID：在 Apple Developer Membership 中查看

  • The team identifier appears in Membership Details after you log into developer.apple.com.
  • Xcode → Preferences → Accounts also shows it for logged‑in teams.

  . Developer ID Application 证书：由 Apple Developer 签发

  • You can let Xcode manage certificates automatically.
  • Create a CSR on your Mac;download & install certificate;it pairs with its private key in Keychain Access.
  • You can verify available signing identities with:

  security find-identity -v -p codesigning
  

  Make sure each listed entry shows both a certificate and its private key .

  Electron 应用怎样保持身份稳定

  {
  再看"name"，"mimo-desktop","version": ".","build": {
  "appId": "com.example.mimo","productName": "Mimo","mac": {
  "target":。"identity": "Developer ID Application: Example Company ","hardenedRuntime": true,"entitlements": "build/entitlements.mac.plist","entitlementsInherit": "build/entitlements.mac.inherit.plist","extendInfo": {
  "NSMicrophoneUsageDescription": "用于在通话中采集麦克风声音","NSCameraUsageDescription": "用于在视频通话中使用摄像头"
  }
  }
  }
  }
  

  • The "appId" should be fixed once released – never change it later.
  • The human‑readable name can vary;it only affects what users see in Finder/Launchpad.
  • The same developer team must sign every build .
  • If you add custom entitlements make sure y are truly needed – extra entitlements enlarge attack surface and complicate notarization.
  • Add Usage Description strings for microphone/camera/etc.;怎么说呢，y explain ***** you ask but do **not** grant permission automatically.* / li>
  • Auxiliary features such as Accessibility or Screen Recording still require manual user approval in System Settings.* / li> <\/ul> A minimal entitlements file might look like this:

    
    
    
    
    com.apple.security.cs.allow-jit
    
    com.apple.security.cs.allow-unsigned-executable-memory
    
    
    
    <\/c ode>

    ---

    如何确认两个包是不是同一个身份

       ，   ，  ，
    
    c
    

    ---

    ---

    ---

    ---

    ---

    bash codesign -dv --verbose= "/Applications/Mimo.app" `Identifier`,`TeamIdentifier`,`Authority`,`CDHash` are shown. The CDHash changes when binary content changes – that's normal. What matters for identity comparison are:

    • Identifier
    • TeamIdentifier
    • Certificate chain
    • Designated Requirement

    Verify signature integrity:

    bash codesign --verify --deep --strict --verbose= "/Applications/Mimo.app"

    Check Gatekeeper assessment:

    bash spctl --assess --type execute --verbose= "/Applications/Mimo.app"

    Read actual bundle id from Info.plist:

    bash /usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' \ "/Applications/Mimo.app/Contents/Info.plist"

    Saving se outputs from both local builds and CI builds lets you compare quickly instead of repeatedly opening System Settings.

    ---

    tccutil reset 能做什么不能做什么 `

    During debugging you can clear specific service grants:

    bash tccutil reset Accessibility com.example.mimo tccutil reset ScreenCapture com.example.mimo tccutil reset Microphone com.example.mimo

    Or wipe all records for a service:

    bash tccutil reset ScreenCapture

    Important: tccutil reset only deletes existing decisions – it cannot simulate a user clicking “Allow”。nor can it migrate permissions from an old Bundle ID to a new one.

    If your goal is to test first‑time authorization flow,resetting helps. If you expect every new build to inherit previous rights automatically,this tool won’t solve that identity problem.

    ---

    一份实用排查清单

    When “permissions disappear after packaging”,follow this checklist:

    1️⃣ Verify that both development and release builds share exactly same CFBundleIdentifier. 2️⃣ Compare TeamIdentifier values shown by codesign. 3️⃣ Confirm you always sign with intended Developer ID Application identity . 4️⃣ Ensure all helper binaries are signed as well . 5️⃣ After signing do not modify any files inside .app;any change invalidates signatures. 6️⃣ Confirm usage description strings are present in final packaged Info.plist. 7️⃣ Identify which process actually triggers permission dialogs – sometimes it’s Electron itself or even Terminal when launched via npm start. 8️⃣ In System Settings check wher stale entries correspond to anor Bundle ID or anor signing team. 9️⃣ In CI pipelines verify that correct .pem/. p12 certificate plus its private key are imported before building. 🔟 Remember: resetting permissions clears decisions only – it does not grant anything automatically.

    ---

    至于最终。稳定的不是文件，而是发布身份

    macOS 权限看起来像是授予一个 .app 文件，但实际依赖的是能够持续验证的 application identity.

    要让升级后的版本继续被程序识别，请务必：

    • ✅ 提前确定并固定 Bundle ID。
    • ✅ 使用 同一 Apple Developer Team 的统一签名流程。其实，
    • ✅ 确保 所有嵌套二进制均已正确签名。
    • ✅ 将开发版与正式版视作独立身份，并接受它们各自拥有独立授权。
    • ✅ 在 CI 与本地机器上都检查最终产物，而非仅检查源码配置。

    下次看到 “换了一个 ID 权限全没了”，不要以为 macOS 随机生成了新密钥——更准确地说是 你的身份证明发生了变化；为了安全起见，程序不会让新的身份自动继承旧身份已有的隐私权限。