Apple still has to work on this, it's not perfect, it's not user friendly, it's not well documented. But here is a working solution.
Beginning from OSX 10.14 (Mojave) you have to ask OSX's System Integrity Protection (SIP) if the user allowed your application to communicate with others.
For making it to work you need to add an entry to your app's .plist file:
key: NSAppleEventsUsageDescription
value: [Some description why you need to use AppleEvents]
Note: You can not use more entries for more applications. Its one entry. So choose your description wisely. This description will be shown in Apple's dialog asking the user for acceptance.
If you have an XPC service like i do, place this in your MAIN app, not in the service.
Now in your application - before using Apple events - check for the current state (if AppleEvents allowed or not). I wrote this method:
- (BOOL)checkSIPforAppIdentifier:(NSString*)identifier {
// First available from 10.14 Mojave
if (@available(macOS 10.14, *)) {
OSStatus status;
NSAppleEventDescriptor *targetAppEventDescriptor;
targetAppEventDescriptor = [NSAppleEventDescriptor descriptorWithBundleIdentifier:identifier];
status = AEDeterminePermissionToAutomateTarget(targetAppEventDescriptor.aeDesc, typeWildCard, typeWildCard, true);
switch (status) {
case -600: //procNotFound
NSLog(@"Not running app with id '%@'",identifier);
break;
case 0: // noErr
NSLog(@"SIP check successfull for app with id '%@'",identifier);
break;
case -1744: // errAEEventWouldRequireUserConsent
// This only appears if you send false for askUserIfNeeded
NSLog(@"User consent required for app with id '%@'",identifier);
break;
case -1743: //errAEEventNotPermitted
NSLog(@"User didn't allow usage for app with id '%@'",identifier);
// Here you should present a dialog with a tutorial on how to activate it manually
// This can be something like
// Go to system preferences > security > privacy
// Choose automation and active [APPNAME] for [APPNAME]
return NO;
default:
break;
}
}
return YES;
}
call it like this:
[self checkSIPforAppIdentifier:@"com.apple.mail"];
You may find detailed information in AppleEvents.h - here's a copy for the used method :
AEDeterminePermissionToAutomateTarget()
Discussion: Determines whether the current application is able to send
an AppleEvent with the given eventClass and eventID to the application
described as targetAddressDesc.
Mac OS 10.14 and later impose additional requirements on applications
when they send AppleEvents to other applications in order to insure
that users are aware of and consent to allowing such control or
information exchange. Generally this involves the user being prompted
in a secure fashion the first time an application attempts to send an
AppleEvent to another application.
If the user consents then this application can send events to the
target. If the user does not consent then any future attempts to send
AppleEvents will result in a failure with errAEEventNotPermitted being
returned. Certain AppleEvents are allowed to be sent without prompting
the user. Pass typeWildCard for the eventClass and eventID to
determine if every event is allowed to be sent from this application
to the target.
Applications can determine, without sending an AppleEvent to a target
application, whether they are allowed to send AppleEvents to the
target with this function. If askUserIfNeeded is true, and this
application does not yet have permission to send AppleEvents to the
target, then the user will be asked if permission can be granted; if
askUserIfNeeded is false and permission has not been granted, then
errAEEventWouldRequireUserConsent will be returned.
The target AEAddressDesc must refer to an already running application.
Results
If the current application is permitted to send the given AppleEvent
to the target, then noErr will be returned. If the current
application is not permitted to send the event, errAEEventNotPermitted
will be returned. If the target application is not running, then
procNotFound will be returned. If askUserIfNeeded is false, and this
application is not yet permitted to send AppleEvents to the target,
then errAEEventWouldRequireUserConsent will be returned.
Mac OS X threading:
Thread safe since version 10.14. Do not call this function on your
main thread because it may take arbitrarily long to return if the user
needs to be prompted for consent.
Parameters:
target:
A pointer to an address descriptor. Before calling
AEDeterminePermissionToAutomateTarget, you set the descriptor to
identify the target application for the Apple event. The target
address descriptor must refer to a running application. If the target
application is on another machine, then Remote AppleEvents must be
enabled on that machine for the user.
theAEEventClass: The event class of the Apple event to determine
permission for.
theAEEventID: The event ID of the Apple event to determine permission
for.
askUserIfNeeded: a Boolean; if true, and if this application does not
yet have permission to send events to the target application, then
prompt the user to obtain permission. If false, do not prompt the
user.
Conclusion:
As mentioned before, it's not perfect.
- The targetted App has to run - otherwise it will return -600
- Once denied, the user can only manually activate it - this does not feel good and smooth.
- Its thread safe, so you should not call it in the main thread (except the dialog for manual activation)