macOS沙盒机制下应用默认隔离，跨App数据共享需通过App Groups（同开发者）或用户授权（第三方），IPC仅支持XPC等系统认证通道，调试需关注TCC权限与security-scoped bookmark生命周期。
macOS 沙盒机制下，应用默认互不可见、互不访问——这不是设计缺陷，而是安全基石。想让两个 App 共享数据或通信，必须走系统认证的路径，不能绕过沙盒边界。
跨应用文件共享：靠 App Groups 或用户显式授权
同一开发者账号下的多个 App，可通过 App Groups 实现容器间数据互通：
- 在 Xcode 中启用 App Groups Capability，并为所有参与 App 声明相同的 Group Identifier（如 group.com.example.shared）
- 共享数据存入 NSFileManager.default.containerURL(forSecurityApplicationGroupIdentifier:) 返回的目录，该路径对组内所有 App 可读写
- 偏好设置、数据库、缓存等均可放在此目录，但需自行处理并发读写（如用 fileCoordinator 或 atomic write）
若非同组 App（如第三方 App 与你的 App），则无法直接共享文件。此时只能依赖用户介入：
- 用 NSOpenPanel/NSSavePanel 让用户手动选择文件或文件夹，获得临时访问权限
- 配合 security-scoped bookmarks 持久化访问路径，下次启动时仍可打开（需 start/stop 配对调用）
- 不能硬编码 ~/Documents 或 ~/Desktop 路径去访问——沙盒会拦截并返回 Operation not permitted
进程间通信（IPC）：只允许通过 XPC 或系统通道
内存共享、文件句柄传递、全局变量等方式全部被沙盒禁止。合法通信必须使用受控通道：
- XPC 是首选方案：服务端 App 声明 XPC Service Bundle ID 并配置 entitlements（如 com.apple.security.application-groups），客户端通过 NSXPCConnection 连接
- 通信双方需签名一致，且 service 的 bundle ID 必须在客户端 Info.plist 的 NSServices 数组中预注册
- 拖放（Drag & Drop）、剪贴板、URL Scheme 调用也受沙盒校验：URL Scheme 必须在 Info.plist 中声明；剪贴板内容若含沙盒外路径，会被自动脱敏
系统级延伸方案：适合强隔离或多环境场景
当 App Groups 或 XPC 不满足需求时，可叠加更高层级的隔离结构：
- APFS 宗卷克隆：用 diskutil apfs cloneVolume 创建逻辑副本，启动后 Safari 缓存、LaunchAgents、Keychain 等完全物理分离，适合开发测试多账号环境
- 多用户账户：不同账户下同名 App 的偏好设置（~/Library/Preferences）、扩展配置、自动登录项天然隔离，无需额外开发，适合终端用户级分身
- iCloud 同步：适用于跨设备、非实时、结构化数据（如用户配置、文档元数据），但不替代本地 IPC；需注意 iCloud Key-Value Store 仅支持小量数据（≤1MB），大文件推荐使用 NSFileCoordinator + ubiquity container
权限与调试关键点
很多通信失败不是逻辑问题，而是权限或配置遗漏：
- 辅助功能权限（如自动化控制）需在「系统设置 → 隐私与安全性 → 自动化」中单独勾选具体进程，而非整个 App
- TCC 数据库记录每项授权状态，撤销后立即生效，无需重启 App
- 日志中看到 EPERM 错误，说明是沙盒策略拒绝；出现 Operation not permitted，则大概率是 security-scoped bookmark 未正确 start 或已失效
- 后台运行受限：未声明 background modes 或未启用 Background App Refresh 的沙盒 App，切到后台几秒即被挂起，XPC 服务也需对应配置
