This is not a new problem but it’s serious enough for me to take time to report that now.
My app sends AppleEvents to other apps, so I’ve added the corresponding tag in the plist file:
NSAppleEventsUsageDescription
This app works by sending events to other apps.
(in an info file dropped to the IDE).
I build the app and run it. Mac OS shows the dialog app wants to send AppleEvents to other app; do you want to allow it? when my app needs it and the AppleEvent works.
In this instance, the key is near the top in the info.plist file:
<?xml version="1.0" encoding="UTF-8"?>
NSAppleEventsUsageDescription
This app works by sending events to other apps.
CFBundleExecutable
My utility
CFBundleName
My utility
Then, I drop my app onto AppWrapper. I don’t use the AppStore. I fill the fields like I think it should be done (I won’t list them all in this post, obviously; available on demand). In the Info tab, I don’t change anything. I wrap the app. In the resulting bundle, the info.plist file keys are reordered (apparently alphabetically):
After making the dmg (using Disk Utility) and notarizing, the keys are ordered again differently (I even got one key/value pair being rewritten as a single line). The app is still unable to send AppleEvents.
Any idea to make the wrapping not breaking the entitlement?
I use NSDictionary functions to manipulate plists, the order of the keys is entirely up to Apple. They even display differently in a NSDictionary than they do in a file.
The “Usage Description” for Apple Script is there.
Harden Runtime is enabled by default (and required for Notarization), this adds extra restrictions to the application, Apple Script can be overridden by selecting the Apple Script entitlement on the “Capabilities” pane.
You can set the Usage Descriptions directly in App Wrapper on the "Privacy’ pane, to which there are now loads and more coming this summer.
I use NSDictionary functions to manipulate plists, the order of the keys is entirely up to Apple. They even display differently in a NSDictionary than they do in a file.
The “Usage Description” for Apple Script is there.
Harden Runtime is enabled by default (and required for Notarization), this adds extra restrictions to the application, Apple Script can be overridden by selecting the Apple Script entitlement on the “Capabilities” pane.
You can set the Usage Descriptions directly in App Wrapper on the "Privacy’ pane, to which there are now loads and more coming this summer.
I hope that this helps.[/quote]
Thanks. I tried these steps but I’m now in a problematic state.
I first tried the step 3 (selecting the Apple Script entitlement). It didn’t worked (same behaviour).
Then, step 4. The wrapped app has the manually-entered-in-AppWrapper entitlement, as expected, but still no working AppleEvents.
Out of idea, I remembered the Diagnose tab always indicate ??? isn’t a valid creator code, so I went in my built app and set an arbitrary creator code. I closed the window in AppWrapper (thinking it would be confused by my external change) and re-opened my app in AppWrapper.
Since then, whenever I type in the Apple Script field (Privacy tab), AppWrapper reports a NilObjectException for the first character entered (even relaunching AppWrapper doesn’t solve the problem).
Tried opening my app in AppWrapper again, the Apple Script field was filled with content I did set earlier (in-between attempts had the field empty; very odd). So I thought about trying wrapping in this state. Wrapping took a unusual amount of time, and I finally got this error returned:
StackOverflowException: 0
RuntimeRaiseException
RuntimeStackCheck
RuntimeUnlockObject
(now, AppWrapper is in the state of Code signing the application with App Wrapper Engine and the progress wheel running, indefinitely; luckily, the Cancel button works).