We have an app that needs Accessibility permissions, to use APIs to listen key board and mouse events.(CGEventTapCreate). The first version is working as expected but after the app update, AXIsProcessTrustedWithOptions returns that app has no accessibility permission but System preferences shows it as enabled.
I’d like to clarify how you’re testing this. There are three potential sequences:
Install just version N (A)
Install just version N+1 (B)
Install version N then update to N+1 (C)
Which of these fail?
Also, make sure to run these tests on a fresh machine each time. A good way to do that is to set up a VM and then restore to a snapshot that’s never ‘seen’ your product before each test.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"Install version N then update to N+1 (C) is failing, Yes our tests are on a VM, each time reverting to a snapshot where product is never tested.
Are you sure that the code signature for version N+1 is compatible with that from version N? Specifically, you should get the designated requirement (DR) for version N and than evaluate that against version N+1.
You can get the DR like so:
% codesign -d -r - /Applications/BBEdit.app
Executable=/Applications/BBEdit.app/Contents/MacOS/BBEdit
designated => anchor apple generic and identifier "com.barebones.bbedit" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = W52GZAXT98)And then test it like so:
% codesign -v -v -R '=anchor apple generic and identifier "com.barebones.bbedit" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = W52GZAXT98)' /Applications/BBEdit.app
/Applications/BBEdit.app: valid on disk
/Applications/BBEdit.app: satisfies its Designated Requirement
/Applications/BBEdit.app: explicit requirement satisfiedShare and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"Our version N is not code signed (code object is not signed at all) and to meet the notarisation requirements, N+1 is code signed and meets the DR, we see the following messages when codesign -v -v -R run on N+1
The issue here is System Prefernces showing as checked but API(AXIsProcessTrustedWithOptions) returning not trusted, after the update if app is not trusted for any reason(code signture compatibility etc), System Prefereces is expected to show it as unchecked so that user can check it .
Right now what is happening, when we guide the users to check the box next to our app, they see it as already checked and not doing anything resulting in app not trusted.
Our version N is not code signed
Yeah, that’s going to present some challenges. Given that you didn’t sign N, there’s simple no way for the system to know that N+1 is an update to that code.
The issue here is System Prefernces showing as checked but API (
) returning not trustedAXIsProcessTrustedWithOptions
Right. Unsigned code is really rare these days, so I’m not super surprised that it confuses the TCC system.
Probably your best option here is to instruct your users to remove the app from System Preferences > Security & Privacy > Privacy > Accessibility and then manually add it back it and then enable it.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"