我们有一个需要访问辅助功能的Mac App Store应用程序。从 10.9 Mavericks 开始，想要使用辅助功能API（系统偏好设置→安全和隐私→辅助功能）的应用程序有一个系统白名单。
在测试我们应用程序的更新时，我们注意到，从旧版本升级后，系统会告诉我们我们无权使用辅助功能 API（AXIsProcessTrustedWithOptions返回 NO ），即使我们的应用程序在白名单上，复选框处于选中状态。一旦我们取消选中并重新检查权限，一切正常。
显然，这对我们来说不是一个可接受的升级方案，特别是因为辅助功能白名单深埋在系统偏好设置中，无法从代码访问。
这是系统错误吗？是否有已知的解决方法？我们会接受在重大更新后必须重新检查辅助功能权限——它只是将您的用户导航到系统偏好设置只是为了看到已经选中的复选框，而该功能不起作用。
更新：
在
首次升级后启动期间，系统会在控制台中抱怨：
16/03/15 06:47:10,343 tccd[190]: Unable to verify code signing identity of com.company.app: code failed to satisfy specified code requirement(s)
16/03/15 06:47:10,350 universalAccessAuthWarn[401]: AccessibilityAPI: pid 471, is not allowed to access the accessibility API. Path: /path/to/app
奇怪的是，一旦取消选中并重新选中可访问性白名单上的权限复选框，即使二进制文件相同，在后续启动期间控制台中也不会出现错误。
我已经偷看了实现访问白名单（/Library/Application Support/com.apple.TCC/TCC.db）的SQLite数据库。access表包含看起来像某些应用程序指纹/哈希 blob 的csreq列：
$ sudo sqlite3 /Library/Application Support/com.apple.TCC/TCC.db 'select client, quote(csreq) from access'
com.apple.dt.Xcode|X'…'
com.apple.AccessibilityInspector|X'…'
com.ourcompany.app|X'…'
（引用的哈希值替换为"..."。
现在，如果我安装旧版本的应用程序并运行它，系统会计算哈希并存储在csreq列中。如果我执行新应用程序版本的全新安装，则会得到不同的哈希。
当我安装旧版本然后删除它时，该列仍包含旧版本的哈希。这可能是问题的根源吗？因为当我在更新应用程序之前将列设置为 NULL 时，一切正常。计算新的哈希，辅助功能 API 检查将按原样返回YES。
GitHub 上不同应用程序中的相同问题。
有一种叫做指定要求的东西（请参阅代码签名指南）。粗略地说，这是系统用来确定两个应用程序捆绑包是否代表同一应用程序（安全方面）的一组标准。可以使用 codesign -dvv --req - YourApp.app 命令显示指定的要求。在我们的例子中，指定的需求检查失败，因为较旧的应用程序版本是使用与开发版本不同的证书签名的。
换句话说，当尝试将Mac App Store版本替换为开发版本时，安全检查将因证书不匹配而失败，您必须重新检查某些应用程序权限。据我所知，当您通过Mac App Store分发并安装相同的版本时，这不会发生。