Recordable application (stopped being recordable)

Our application (sandboxed, on the mac) sends Apple Events to itself for being recordable in Script Editor.

Alas, I just noted that this feature stopped working, i.e. at least under macOS 12.4 Script Editor does not see what our application does. I am not sure when (i.e. under what macOS) recordability stopped working, but it is gone on 12.4.

We have tried, (for testing), to set the sandbox exception com.apple.security.temporary-exception.apple-events to true, but it makes no difference.

I know that Apple Script in general, and recordability in particular, are badly out of fashion these days, so we are considering dropping recordability anyway. But if there's an easy way to keep it working, I'd be interested.

Thanks for any advice in advance

Answered by kusu in 718661022

Okay, I spent an inordinate amount of blood, sweat, and tears reading the archived (i.e. obsolete) documentation as well as the cryptic modern one. I also checked what other apps do. Finally, I have been able to make recording work. In case anyone ever tries to make their application recordable, here's what I've found out:

In order to be recordable by Script Editor, an application needs to have the following entries in its entitlements file:

	<key>com.apple.security.automation.apple-events</key>
	<true/>

	<key>com.apple.security.temporary-exception.apple-events</key>
	<array>
		<string>com.apple.ScriptEditor2</string>
	</array>

In addition, and this was the hardest part, it also needs to explain why it wants to send Apple Events to Script Editor. And this explanation has to go into the application's info.plist file under the NSAppleEventsUsageDescription key, e.g. something like this:

	<key>NSAppleEventsUsageDescription</key>
	<string>xxxxx needs to send Apple Events to Script Editor to allow Script Editor to record what you do in xxxx</string>

(Without the NSAppleEventsUsageDescription, Script Editor never gets any Apple Events it can record. Once you have entered this and you operate your app while Script Editor is recording, a dialog box will come up that asks the user to confirm that the app is allowed to send Apple Events to Script Editor. Once the user confirms, the setting is reflected in System Preferences -> Security & Privacy -> Privacy -> Automation)

Finally, here are some useful hints for debugging:

When you change any of the above entries in order to see how your app behaves after the change, it's a good idea to reset the system's privacy settings using tccutil in Terminal:

tccutil reset AppleEvents your_bundle_id

If you want to peek at the entitlements of your or any other app, use codesign in Terminal:

codesign -d --entitlements - path_to_your_app

I hope this helps someone out there.

Now for the next challenge: Getting the entitlements through the App Store Review. (I am not too optimistic.)

Accepted Answer

Okay, I spent an inordinate amount of blood, sweat, and tears reading the archived (i.e. obsolete) documentation as well as the cryptic modern one. I also checked what other apps do. Finally, I have been able to make recording work. In case anyone ever tries to make their application recordable, here's what I've found out:

In order to be recordable by Script Editor, an application needs to have the following entries in its entitlements file:

	<key>com.apple.security.automation.apple-events</key>
	<true/>

	<key>com.apple.security.temporary-exception.apple-events</key>
	<array>
		<string>com.apple.ScriptEditor2</string>
	</array>

In addition, and this was the hardest part, it also needs to explain why it wants to send Apple Events to Script Editor. And this explanation has to go into the application's info.plist file under the NSAppleEventsUsageDescription key, e.g. something like this:

	<key>NSAppleEventsUsageDescription</key>
	<string>xxxxx needs to send Apple Events to Script Editor to allow Script Editor to record what you do in xxxx</string>

(Without the NSAppleEventsUsageDescription, Script Editor never gets any Apple Events it can record. Once you have entered this and you operate your app while Script Editor is recording, a dialog box will come up that asks the user to confirm that the app is allowed to send Apple Events to Script Editor. Once the user confirms, the setting is reflected in System Preferences -> Security & Privacy -> Privacy -> Automation)

Finally, here are some useful hints for debugging:

When you change any of the above entries in order to see how your app behaves after the change, it's a good idea to reset the system's privacy settings using tccutil in Terminal:

tccutil reset AppleEvents your_bundle_id

If you want to peek at the entitlements of your or any other app, use codesign in Terminal:

codesign -d --entitlements - path_to_your_app

I hope this helps someone out there.

Now for the next challenge: Getting the entitlements through the App Store Review. (I am not too optimistic.)

In case someone else is fighting this issue: Even though the above technically solves the issue, it gets the app rejected in the app store. (Even though we've explained why we are using it.)

Well, I am not surprised that there are almost no recordable apps out there. :-/

Which recordability approach do you use:

  • Do you use send-to-self events and than act on them?

  • Or do you do the work internally and record it using events sent with kAEDontExecute?

Share and Enjoy

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

kAEDontExecute it is, i.e. we're not acting on them, they're only about being recordable. Would that make a difference?

Would that make a difference?

Honestly, I don’t know enough about how Apple event recording works to answer that. I was just trying to scope the issue.

[Quinn looks at how Apple event recording works under the covers.]

I’d completely forgotten that AE recording lets multiple apps record Apple events. The system keeps track of which apps are recording and passes that list to every app that generates Apple events. When an app generates an Apple event, it sends a copy of that Apple event directly to each recording app. These copies are tagged with a special attribute ('frec') so it’s certainly would be feasible for the App Sandbox / Automation privilege to allow them without the sender needing any special privileges.

However, AFAICT that’s not happening right now and there’s no good way for you to work around that limitation [1]. My only advice here is that you file a bug about that.

Please post your bug number, just for the record.

Share and Enjoy

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

[1] Due to the way that recording works, your com.apple.security.temporary-exception.apple-events workaround is both simultaneously too broad (it lets you automate Script Editor) and not broad enough (it won’t fix the problem for other recording apps).

Thanks for this. This is what I was afraid to hear. Well, I presently have a case open with DTS on the issue. So far, they have just told me that they cannot comment on App Store Policies, but I have now explained to them it's (obviously) not policies I want to talk about, but I need a technical solution that's compatible with these policies. Not holding my breath there, and if nothing helpful comes back, I will post that bug report.

(I think that recordability is one of the unique things of macOS, or it would be if it were used by more apps—it's dawning on me now why it isn't. And yes, I know that my workaround does not solve the issue for other recording apps. But I doubt that recording apps have a future the way things are right now.)

Just one more thing, and I guess you know it: @eskimo, your competent and to-the-point replies on this forum are a great help to all the developer community. Thanks for that!

I was on a holiday, but now I have filed the feedback you suggested.@eskimo. The feedback number is FB11219624

Recordable application (stopped being recordable)
 
 
Q