bring up onboarding UI right after launch. If the app knew that authorization has not yet been requested, it could, f.ex. Without information on its current authorization status, an app can't time when the user is asked for authorization. Problem 1: authorization status is not available to appsĪs of macOS Mojave beta 2, apps can't get their current Apple Event authorization status.

the user is only ever prompted once for every sender / recipient pair.

Recipient.app is launched every time an Apple Event is sent in its direction - even if the user has chosen 'Don't allow' before and the Apple Event isn't delivered.

This - and future Apple Events from Sender.app to Recipient.app - are delivered without prompting the user again. The error code errAEEventNotPermitted (-1743) is returned to Sender.app for this and other Apple Events sent to Recipient.app in the future.

Don't Allow: the thread resumes execution.

The user can then choose between these two options:

Recipient.app is launched, if it's not already running.

the Sender.app thread sending the Apple Event is blocked.The first time Sender.app sends an Apple Event to Recipient.app: However, the current implementation turns out to be problematic for many legitimate, privacy-respecting apps in (at least) the automation, accessibility, device management, utility and remote control categories. One of them - and possibly the one with the biggest impact: apps can no longer send Apple Events to other apps without user authorization.Īpple argues that Apple Events (which AppleScript uses under the hood) can be used to get access to otherwise protected user data in other apps, so the user should be prompted for authorization. In the WWDC 2018 session 'Your Apps and the Future of macOS Security', Apple announced big changes to macOS security.

Apple sandbox os