My app is designed to send AppleEvents to the music app of MacOS. Previously, that was iTunes, now it’s Music.
On my 12.0.3 system, my app doesn’t work anymore; the AppleEvents are just not being sent. I can target Music just fine using the Script Editor, so I’m guessing the OS is preventing my app to automate Music (is there a way to be sure of that, btw? A log in Console or getting an error code?).
In Security&Privacy (System preferences), in the Automation pane, my app isn’t listed. As this pane is among the rares to have no “add” button, I can’t add it manually. And the OS won’t ask me whether I want to allow the app to control Music, despite my attempts and having restarted the computer.
It’s all about the debugged app; I’ve not tried the built version because it would be a pain to debug with always building the app.
So it seems I can only sit here and observe my app’s inability to automate Music.
Apple’s new “security” rules are just plain wrong, or there’s something to try?
As far as I know, this intended stopped working with macOS 12
I remember reading a workaround on StackOverFlow but that was more or less a hack. So not sure if that’s a solution either.
Apple intentionally broke/prevented AppleEvents from working? Why is that?
It’s one core of the functionalities of the OS, and one reason I prefer MacOS over the others. Please don’t tell me they are abandoning that!
Thanks.
Wasn’t this optional for debugged apps, though?
It’s the first time I encounter a need to also use AppWrapper for a debug session. Is that even doable?
Thanks.
Edit: probably doable with “run paused”, but notarising my app each time I debug is going to be unpleasant…
For debugged apps you don’t need the plist entry. Do you check the AppleScript permissions?
'get permissions for new app
dim target as NSAppleEventDescriptorMBS = NSAppleEventDescriptorMBS.descriptorWithBundleIdentifier(BundleID)
// we ask for all apple events
PermissionsForApp = NSAppleScriptMBS.DeterminePermissionToAutomateTarget(target, "****", "****", true)
PermissionsDictionary.Value(BundleID) = PermissionsForApp
dim target as NSAppleEventDescriptorMBS = NSAppleEventDescriptorMBS.descriptorWithBundleIdentifier(MusicBundleID)
// we ask for all apple events
Var PermissionsForApp as integer=NSAppleScriptMBS.DeterminePermissionToAutomateTarget(target,"****","****",true)
Var PermissionsDictionary as new Dictionary
PermissionsDictionary.Value(MusicBundleID)=PermissionsForApp
MusicBundleID being set to com.apple.Music.
I’m seeing that PermissionsForApp returns -1743 (errAEEventNotPermitted).
Usability should be more important than security, IMO.
I extensively use AppleEvents in many of my apps, so I can’t believe they are going away. Also, my other apps still work with AppleEvents
You need to have all pieces in place and only the the §$%& AppleScripts work. I’ve had some fun with them some weeks ago. AppWrapper overwrote something that it shouldn’t have.
Start with something simple. Try the examples of the MBS plugin.
Well, another of my app, a “complex” one, is currently working fine with AppleEvents (both as debugged and compiled), so I’m already in this state. The differences I can see is the working app doesn’t target Music and is listed in the Automate pane in Security&Privacy.
Thanks.
Not yet. I even run-paused the application (from the IDE) and notarised it (using AppWrapper), it failed as well.
I’ll search on the web whether Apple has specifically blocked AppleEvents sent to Music, soon.
Thanks. Tried that and received a successful response, but still the same behaviour about the app. Do I need to restart the computer? (which I usually hardly do, having always a ton of app used at the same time, hence the reason I ask instead of trying).
Have you looked in the Privacy panel in System Preferences to see if your app is blocked from doing anything? Once an app is blocked, the user has to be the one to go unblock it. Requesting again will just get denied straight off.
tccutil should reset any blocks, and you will be challenged the next time you try to send the AppleEvent.
The effect of tccutil reset doesn’t require rebooting in my experience. You can test that it worked by sending an AppleEvent to an app you’ve had success with before – you should see the “allow” dialog again.
Yes, my app doesn’t appear in the Automation pane (and there’s no option to add or remove it, so it’s implicitly blocked, since the OS has not added it there (nor asked me if I want to allow sending AppleEvents)).
The challenge for me is rather that the OS has never asked me if I want to allow these AppleEvents, even after trying the tccutil command.
Currently, it’s a mess. My other apps can’t send AppleEvents anymore. On the other hand, I’ve found my app to be listed in “Developer Tools” (a pane in Security&Privacy that doesn’t even have an icon, as if it’s a legacy pane). I’ve removed from there, but the issue remains. At this point, I’m going to restart the computer.