Specifically, UI Browser calls my framework's Objective-C wrapper methods for accessibility functions like AXIsProcessTrustedWithOptions(). These calls have begun to fail in recent GM releases of Yosemite. Console.app reports things like this:
2014-10-12 11:04:01.213 AM tccd[223]: Unable to verify code signing identity of com.pfiddlesoft.uibrowser: the code on disk does not match what is running
2014-10-12 11:04:01.216 AM universalAccessAuthWarn[1793]: AccessibilityAPI: pid 21235, is not allowed to access the accessibility API. Path: /Users/cheeseb/Desktop/UI Browser/Applications/UI Browser.app/Contents/MacOS/UI Browser
The code signing warning is surprising, because both the UI Browser application and the framework pass all of the codesign tests for proper signatures on disk.
I'm guessing from the wording of the code signing warning that Yosemite now disallows the use of accessibility calls made in a separate, shared framework. When I remove calls to my framework from UI Browser and call the AX... functions directly, they work without error. Is this the direction apple is moving in Yosemite?
If that is the case, can I still use my framework by embedding it in UI Browser instead of using it as a shared framework? I ask, because it will be a big job to make that change just to find out if it works.
It also occurs to me that this problem might not be unique to accessibility. Is code signing now making it impossible to use shared frameworks at all, going forward? That would be a huge change to spring on the developer community without advance warning.