Hardened Runtime 和 App Sandbox 都有访问权限控制，例如“通讯录”、“日历”、“位置”等，它们有看起来重复的参数，但实际上它们作用不同、是互补的机制。
App Sandbox（应用沙盒）
1、作用：限制 App 对系统资源的访问（强制访问控制）。
2、重点：默认阻止一切访问，除非在 .entitlements 文件中显式声明权限。
3、是否必须：App Store 必须开启。非 App Store 分发（通过 notarization）可以不开启，但建议使用。
4、App Sandbox权限（在 .entitlements 中）：
如果不开启 App Sandbox，即使请求系统权限弹窗，也可能访问不到真实数据（系统不允许访问）。
Hardened Runtime（强化运行时）
1、作用：增强运行时的安全性，防止调试、注入、JIT 攻击等。
2、重点：用于代码签名 + Notarization 公证。
3、是否必须：App Store 分发：默认必须开启。非 App Store 分发：建议开启（尤其 Notarization 必须）。
4、Hardened Runtime 权限：在开启 Hardened Runtime 时，有些功能需要在签名时用 –options runtime 并在签名中添加特定 flag，如：
codesign --options runtime --entitlements your.entitlements ...比如：
1、摄像头：需要 com.apple.security.device.camera。
2、麦克风：需要 com.apple.security.device.audio-input。
3、Apple Events：需要 com.apple.security.automation.apple-events。
两者设计目标
App Sandbox和Hardened Runtime存在权限的重叠，例如都可以授权摄像头、麦克风、位置等功能，两者实际存在权限控制的区别。
App Sandbox 控制可以访问什么的权限（例如“你可以访问联系人”）；
Hardened Runtime 控制在可以访问的时候，触发系统弹窗 & 用户授权（例如“用户是否允许访问联系人”）。
可能会疑问，既然 App Sandbox 已经控制权限了，为什么 macOS 不直接由它也处理系统弹窗和用户授权，而是又搞了 Hardened Runtime 单独处理弹窗？
这其实是 Apple macOS 权限模型中的设计分层哲学，可以总结为一句话：
App Sandbox 负责的是开发者的声明（declare what you need），Hardened Runtime 负责的是系统对用户的保护（enforce runtime user consent）。App Sandbox ≠ 权限弹窗系统，它是“权限边界”
App Sandbox 是一种静态的、文件级的“能力声明与隔离机制”：
它是系统级强制访问控制（Mandatory Access Control）的一部分，目的是限制 App 访问文件系统、网络、摄像头等资源。
它工作在内核级别，一旦你访问了未声明的资源，系统直接拒绝，甚至不会到用户态处理。
它不负责动态交互，也就是说：App Sandbox 不会也不能弹窗，因为它的责任是：“不在权限列表内，就永远不让你碰到这个资源。”
Hardened Runtime 是用户态的“执行守门人”
Hardened Runtime 是一个运行时安全框架，由 Apple 在 macOS Mojave（10.14）引入，初衷是为了支持 Notarization（应用公证），并抵御以下攻击：
1、动态代码注入
2、插件劫持
3、JIT 执行绕过
4、未授权访问敏感数据（如通讯录、摄像头）
它做了两件事：
1、为了用户安全，引入了隐私权限弹窗（TCC framework，Transparency, Consent, and Control）。
2、提供运行时安全防护，只有 Hardened Runtime 启用后，TCC 弹窗才工作。
所以 macOS 的 TCC 权限系统（弹窗/授权），依赖于 Hardened Runtime，而不是 Sandbox。
为什么不把两者合并？历史 & 兼容性原因
iOS 权限设计 = 沙盒 + 弹窗集成
因为 macOS 兼容历史上很多不使用 Sandbox 的老 App、命令行工具、插件程序。如果弹窗功能绑定在 App Sandbox 上，会导致：
旧 App 无法访问联系人、相册（因为没开启沙盒）；
命令行工具（无 GUI）也不能弹窗请求授权；
会破坏大量 macOS 上已有生态。
所以 Apple 折中做法：
保留 App Sandbox 用于声明资源访问范围；
把弹窗授权系统（TCC）挂在 Hardened Runtime 上；
再通过 Notarization 要求大家逐步启用 Hardened Runtime。
总结
App Store 分发时，建议开启 App Sandbox + Hardened Runtime，声明所需所有资源访问权限。
Notarization 分发（非 App Store）时，开启 Hardened Runtime，按需决定是否开启 App Sandbox，但仍需声明权限。
想访问通讯录、日历等敏感数据时，两边都需要写：Sandbox 控制“允许访问”，Hardened Runtime 控制“系统弹窗和权限授予”。
如果开发的是 macOS 应用、需要访问敏感资源（比如照片、联系人、摄像头），必须同时：
1、在 .entitlements 中添加 Sandbox 权限（如果开启了 Sandbox）。
2、启用 Hardened Runtime（触发弹窗授权）。
3、在代码中触发访问，系统才会弹出权限请求框。
相关文章
1、macOS管理App Sandbox权限：https://fangjunyu.com/2025/06/20/macos%e7%ae%a1%e7%90%86app-sandbox%e6%9d%83%e9%99%90/
2、macOS安全机制Hardened Runtime（强化运行时）：https://fangjunyu.com/2025/06/22/macos%e5%ae%89%e5%85%a8%e6%9c%ba%e5%88%b6hardened-runtime%ef%bc%88%e5%8a%a0%e5%9b%ba%e8%bf%90%e8%a1%8c%e6%97%b6%ef%bc%89/
