I was on a holiday, but now I have filed the feedback you suggested.@eskimo. The feedback number is FB11219624
Post
Replies
Boosts
Views
Activity
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!
kAEDontExecute it is, i.e. we're not acting on them, they're only about being recordable. Would that make a difference?
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. :-/
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.)
It's beyond annoying that the only way most people see that the Account Holder has to "agree" to a new agreement is at the moment when they are trying to submit an app for review.
Absolutely