Unity 2020.2.x导出Mac构建上传下载后提示应用已损坏问题咨询

这个问题并非项目配置、上传平台故障或是网络传输导致的文件损坏，是Unity 2020.2.x版本的Mac导出流程内置逻辑与macOS Gatekeeper校验规则冲突引发的固定问题：

• Unity 2019.3.4f1及更早版本的Mac导出流程，不会主动向生成的.app应用包内部的可执行文件、资源文件写入自定义扩展属性（xattr）。应用经过zip压缩、网络上传下载后，系统只会在首次解压时给包打上统一的下载隔离标记，Gatekeeper校验应用代码签名通过后，就会正常弹出首次运行的权限请求，不会触发异常。
• Unity 2020.2.x版本调整了Mac导出的内部逻辑，会在导出.app包的过程中，主动给包内多层级的文件写入和隔离属性、来源标记相关的自定义扩展属性。当这个携带多层扩展属性的.app被打包成zip、经过网络传输、在其他设备上重新解压时，macOS的Gatekeeper机制会识别到包内预先写入的扩展属性和当前设备的来源标记不匹配，叠加zip格式对扩展属性的保留、还原逻辑存在兼容性问题，最终会导致应用的代码签名校验链路断裂，直接弹出“应用已损坏，无法打开，你应该将它移到废纸篓”的错误提示。
• 这种内置行为不受项目内容、导出配置、上传站点类型的影响，哪怕是不包含任何业务逻辑的全新空白项目，只要使用该版本Unity导出Mac构建产物，就会触发这个问题。

• 方案1：导出构建完成后、压缩上传前，清除.app包内所有自定义扩展属性
  在终端定位到构建产物的存放目录，对目标应用执行递归清除扩展属性的命令：xattr -cr 你的应用名称.app。命令执行完成后再将整个.app文件夹压缩为zip上传即可。这个操作会彻底移除Unity预先写入的、会触发校验异常的扩展属性，后续经过网络传输下载解压时，系统会自动给应用打上正常的隔离标记，Gatekeeper可以正常完成签名校验，不会弹出损坏提示。
• 方案2：通过Xcode中转完成最终打包
  在Unity导出Mac构建时，勾选Create Xcode Project选项，先导出未完成最终签名的Xcode工程，再在Xcode中完成应用签名、打包流程生成最终的.app产物。这种流程下Unity不会向包内文件写入自定义扩展属性，最终生成的应用包完全符合macOS的文件属性规范，经过压缩传输下载后不会触发校验错误。
• 方案3：用户侧应急处理（仅适合内部测试场景）
  对于已经下载了异常应用的用户，可以在终端执行命令sudo xattr -rd com.apple.quarantine 应用存放路径/你的应用名称.app，清除应用的隔离属性标记后即可正常打开。但这个操作需要用户手动执行终端命令、输入管理员密码，操作门槛较高，不适合面向普通用户的正式分发场景。

内容的提问来源于stack exchange，提问作者Robert O'Connor