tccd reports Apple Events entitlement check error, despite a process having it

HI! I am developing an application that should utilize ScriptingBridge.framework to interact with another process. Firstly, I created a separate test application for which I have added Apple Events entitlements via "Signing & Capabilities" section in Xcode and updated its Info.plist to have "Privacy - AppleEvents Sending Usage Description". While the test app works fine (I see an automation request popup and the process executes as expected) the main application where I want to integrate this functionality gets closed immediately after reaching the code interacting with Scripting Bridge. On its launch, I see the following error message from tccd in Console:

Prompting policy for hardened runtime; service: kTCCServiceAppleEvents requires entitlement com.apple.security.automation.apple-events but it is missing for accessing={TCCDProcess: identifier=<app bundleID>, ..., binary_path=<path to the app's binary>}

I had no such issues with the test app. Moreover, I should mention that the bundle I want to have with such functionality is stored in another bundle, both main and inner bundles aren't sandboxed, and the target app has Application is agent (UIElement) key set in Info.plist. Can you suggest any ideas as to why processes behave so differently despite having pretty much the same build configurations?

I need to get a better understanding of how this is set up in your real product. You wrote:

I should mention that the bundle I want to have with such functionality is stored in another bundle, both main and inner bundles aren't sandboxed, and the target app has Application is agent (UIElement) key set in Info.plist.

Let’s call these your container app and your UI element app. Questions:

  • The UI element app is an app, right? Not something else, like an app extension.

  • Are either of these sandboxed?

  • Where did you app the Apple event capability? On the UI element app?

  • In that TCC error, which bundle ID and path are shown? The container app? Or the UI element app?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Sorry, responded in the comment section. Duplicate as a reply:

Ok, considering only the real product:

The UI element app is an app, right? Not something else, like an app extension.

Exactly, that is an app not an app extension or anything else

Are either of these sandboxed?

They aren't sandboxed

Where did you app the Apple event capability? On the UI element app?

Yes, on the UI element app via Xcode "Signing & Capabilities"

In that TCC error, which bundle ID and path are shown? The container app? Or the UI element app?

UI element app

Thanks for the answers.

Let’s rule out the UIElement factor first. If you temporarily remove that key from your UI element app, allowing it to run with a UI, does that help?

Note that you might need to add a dummy main menu nib to allow AppKit to start up with a UI.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Tested with your suggestion the issue persists. The error message from tccd persists, the UI element app app gets closed on calling SBApplication(bundleIdentifier:). No crash reports in Console.

Hmmm, I’m not aware of any way that TCC will terminate an app. If there’s no crash report, it’s likely that TCC is triggering an error and something within your app is exiting in response to that error.

Does this happen if you run the UI element app under the debugger? If so, what does it report about the termination?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi, eskimo! Finally, I was able to check that. This termination mystery was solved: an exit() statement caused app termination. The statement was in the program itself and it had nothing in common with tccd.

However, the issue with tccd that caused the creation of this thread persists. It continues to report the absence of entitlements for Apple Events despite the fact, that the bundle has it.

If we return to our naming convention: "UI element app" is a user agent that has the corresponding plist and gets launched via launchctl command from "container app". UI element app bundle is a part of the container app bundle.

Considering these conditions is it possible that the issue may be with the container app not having the required entitlements?

It sounds like you’re not using SMAppService to set up your launchd agent. Given that, you should list your main app’s bundle ID in AssociatedBundleIdentifiers. Are you doing that already? If not, please try it out?

See the launchd.plist man page for details.

Also, make sure you test on a ‘clean’ machine. I generally test this stuff on a VM, restoring from a snapshot before each test.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Probably you are right, I am going to check with your suggestions, thank you! So far I have modified the UI element app so I can run it as a standalone GUI-less app (via Xcode without launchctl invocation or by double-clicking on the bundle). By GUI-less I mean with "Application is agent" key set to YES in Info.plist and without "Main storyboard" key. In this configuration, the app can acquire Automation permissions and interact with Finder via Scripting Bridge.

tccd reports Apple Events entitlement check error, despite a process having it
 
 
Q