This was my first real experience trying to write a Mac app after years of doing iOS development and the majority of my time was spent trying to understand how sandboxing works and which entitlements I needed to specify. Not much of a “win” for developers if you ask me. And the end results for users are extremely confusing permissions dialogs.Įven the big news about Transmit 5 coming back to the Mac App Store was not that promising considering it is still missing some functionality and required six different kinds of temporary entitlement exceptions, some of which you must request special access to use. In practice however, it is extremely frustrating for developers who have to navigate a labyrinth of obscure entitlement options, some of which do not yet exist for functionality we want to provide. Generally, app sandboxing seems like a good feature to protect users. About four years later, and no additional access groups have been added. In fact, the only one available is .position, which looks like it was added because of this radar from Craig Hockenberry. Sdef /System/Library/CoreServices/System \ Events.app > ~/Desktop/system_events_sdef.xmlĪnd disappointment ensues. I wondered if this would this be allowed in the Mac App Store? But, now my app worked as expected. The “temporary exception” in the key name was worrisome.
I needed to add the following entitlement to my App.entitlements file. The scripting-targets entitlement is the preferred way to request the ability to send Apple events to apps that provide scripting access groups, as described in App Sandbox Entitlement Keys. However, with App Sandbox you cannot send Apple events to other apps unless you configure a scripting-targets entitlement or an apple-events temporary exception entitlement. There’s an entire section on temporary exceptions for AppleEvents. Apple considers feature requests as it develops the macOS platform. If you need to request a temporary exception entitlement, use Apple’s bug reporting system to let Apple know what’s not working for you. Now I had something to search for in the Mac developer docs, and I found this guide on Temporary Exception Entitlements.Ī temporary exception entitlement permits your macOS app to perform certain operations otherwise disallowed by App Sandbox. I continued to see the “System Events isn’t running” error.Īfter some digging around, I learned about the -exception.apple-events entitlement, buried in this StackOverflow post. Unfortunately, the app still did not work. This is exactly how iOS permissions operate, so it was a familiar solution to me. Updating plist keys and entitlementsīased on the readings above, the solution was to add the NSAppleEventsUsageDescription key to my ist. Those posts clearly explain the problems and how the new limitations negatively affect developers and users. In short, there are new sandboxing restrictions in Mojave for AppleEvents - the macOS mechanism for automation (like AppleScript) and other communication between applications.
I suggest reading those posts to get the full picture. I do not follow the Mac developer scene closely, but it looks like there had been issues with these APIs since the early betas of Mojave. macOS Mojave gets new APIs around AppleEvent sandboxing - but AEpocalypse still looms.Apple Event sandboxing in macOS Mojave lacks essential APIs.It did not take long to find these posts by Daniel Jalkut and Felix Schwarz: My guess was that this was a permissions issue.
NSAppleScriptErrorMessage = "System Events got an error: Application isn't running." NSAppleScriptErrorBriefMessage = "Application isn't running."