The user has 2 computers. One one computer my app works fine. On the second one the app is declining Automation approval on it’s own. I let the user reset Automation with a Terminal command. Then I made him a test app with the following code from the MBS plugin examples:
dim target as NSAppleEventDescriptorMBS = NSAppleEventDescriptorMBS.descriptorWithBundleIdentifier("com.apple.Mail")
// we ask for all apple events
dim e as integer = NSAppleScriptMBS.DeterminePermissionToAutomateTarget(target, "****", "****", true)
if e = 0 or e = -1 then
MessageBox "everything okay"
else
MsgBox str(e)+": "+errorToString(e)
Return
end if
The full app has the usual plist, codesign, notarisation. I made sure that the test app has the same.
Neither the full app or the test app show up in the Automation pane at all for the user.
Instead of getting the usual “blabla wants to control Mail” the result is an error -1743: Not permitted. Any ideas what else I could try to get Automation working?
One user solved the problem on his own. I just did a screensharing with another user and everything works fine on his computer. I don’t know what he did before.
Do a “tccutil reset AppleEvents” in Terminal.
Start version 6.1.3 of my app. Get mailboxes from Mail: everything is okay.
Do a “tccutil reset AppleEvents” in Terminal.
Start version 6.2 of my app. Get mailboxes from Mail: no dice.
If there is no NSAppleEventsUsageDescription then I get the same result -1643 “don’t wanna” instead of asking for the permissions.
I don’t have a plist file but do everything in an IDE script with localisation:
command = "/bin/echo 'NSAppleEventsUsageDescription = ""Mail Archiver uses AppleScript to communicate with Mail and Outlook, Filemaker.""; '>>" + appPath + "/Contents/Resources/en.lproj/InfoPlist.strings" Call DoShellCommand(command)
The strings are in the plist where they should be.
Why does the app get the NSAppleEventsUsageDescription in debug and after building but not in the notarized dmg?
There are indeed no privacy usage strings in your test applications plist. I don’t think it is a bug with App Wrapper as App Wrapper also uses them (you can check the App Wrapper plist file if you like).
I am a bit confused, you say you don’t use a plist, but then say they’re in the plist. AFAICT that command line snippet processes the localized version of the strings and NOT the actual plist.
I think I need more information for this.
Start by building a version of your application, ensuring the keys are in the plist file. Then drag that application to App Wrapper to process it, once the wrapped version of the application and check the plist. Notarize it and then check the plist of the Notarized version.
Otherwise please send me a copy of the unwrapped application and your App Wrapper data file, so I can attempt to reproduce it here.
I can confirm that your project built with 2021r1, works in debug while unsigned and not including the Usage strings in the actual plist file. I did have to replace the MBS AppleScript code with OAK AppleScript code.
Wrapped with App Wrapper, using your App Wrapper file, it continues to work.
Unselected the option in the “Automation” section of “Security & Privacy” and it gives me the error message “Not Authorized”.
Using your commandline function to reset TCCs does indeed make the application return “Not Authorized”.
Firing up “Find Any File” asks me to Authorize it.
Attempting to use AppleScript from App Wrapper also asks me to authorize it.
Success - Enabling AppleScript in the Capabilities pane of App Wrapper and setting a Usage string “Mail Archiver X can then access mail in Apple Mail and others”. Then asked me to authorize when I re-opened your demo application.
So it appears that Apple have different rules for unsigned applications and signed applications, which quit frankly is not surprising as they’re about as well organized as I am (which is not).
I see, so the AppleScript is being called from a Helper. Is the helper being launched by the main application or another application, say the commandline or a something?
Is the final application for the Mac App Store or website deployment?
Click on the “Options” button next to “Code signing” in the sidebar and check the "Nested executable entitlements popup menu.
Default - Will pick what App Wrapper understands to be the best method. With the App Sandbox, it uses “Inheritance Plus” otherwise “main”.
Inheritance Plus - Uses Inherited Entitlements, as well as including certain entitlements for Hardened Runtime.
Inheritance - Uses Inherited Entitlements for nested executables.
Main Entitlements - Uses the exact same entitlements for the main application and nested components.
AppWrapper is overwriting the existing entitlements. In the old version of my app I used an entitlement plist file and did the codesign in code. The current version should use only AppWrapper for codesigning, creating the dmg and notarisation. But I forgot to take out the codesign.
I just did a test where I built the app and then only used “Pack & Notarise” instead of “Wrap, Pack & Notarise” and I finally got the automation correct. Now the path of the second app in the dmg is wrong but at least I’m making progress.
How can I script AppWrapper not to do a codesign? Using “Wrap, Pack & Notarise” fubars the Automation security even with "“Nested executable entitlements” set to none.
If necessary I can do my app in 2 steps for a while.
