App Sandbox and Apple Events - supported alternatives for Finder and Terminal integration?

Most of your questions are about App Review policy. I don’t work for App Review and can’t give you definitive answers about their policy. If you need that, I suggest you contact them directly.

I do have some technology-focused answers though:

Are Finder Sync extensions … recommended for these use cases?

No. Finder Sync extensions are intended to be use to manage syncing the file system with a cloud-based file store. If you try to use them for other tasks, you inevitably run into problem. If you review the various threads with the Finder Sync tag, you’ll see a bunch of cases where developers who’ve not followed this advice have come a cropper.

Are … Accessibility APIs … recommended for these use cases?

The docs specifically call out that accessibility APIs aren’t supported by App Sandbox.

Are … macOS Services … recommended for these use cases?

That’s definitely something you should investigate. Critically, the user can associated a keyboard shortcut with a service, which also gets you out of the hotkey business.

My general take on this is that you should make your app scriptable, either via AppleScript or by Shortcuts. Once you do that, the user can use the system’s scripting facilities to invoke your app from the right context. That puts the user in charge, which in turns means that you run into less security roadblocks.

For example, if you support an Apple event to act on a specific directory, then the user can:

1. Create a script that gets the current working directory from Terminal and invokes that Apple event on your app.
2. And run that from the Script menu, or from whatever other automation app they use (for example, I might invoke it via Keyboard Maestro).

This has a bunch of advantages:

• The user can customise this to work with their preferred terminal app.
• The Apple event gives you the current working directory path…
• And, critically, it includes a security-scoped URL that grants you access to that directory.

The downside is that it’s a bit of a faff for users to set up, but you can assist them with their in your documentation. And if you’re target market is folks using Terminal, it’s a reasonable bet that your typical user a) can achieve this goal, and b) would appreciate this level of customisation.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I'm trying to understand the recommended, App Store-compliant approach rather than relying on temporary sandbox exceptions.

There is none. Direct integration with the Finder and Terminal is strictly off limits.

Is there an officially supported way for a sandboxed app to retrieve Finder's current selection when triggered by a global keyboard shortcut, without Apple Events?

No. But you can create a service that the user can invoke via Finder's context menu when selecting a folder. Obviously this is not the same as what you're asking, but that's as close as you can get.

Is accessing Terminal's current working directory supported under App Sandbox with explicit user consent?

No. Terminal-savvy users can access your app from the command line. However, your app would still be sandboxed and unable to do anything with files in the current Terminal directory.

Are Finder Sync extensions, Accessibility APIs, macOS Services, or other frameworks recommended for these use cases?

No way to say without knowing what you're really trying to accomplish.

Are temporary Apple Events exceptions generally unsuitable for Mac App Store distribution, even when the interaction is explicitly initiated by the user?

As I said, App Review doesn't allow any apps to directly integrate with the Finder or Terminal. There are other ways to achieve some of the same results, if only I knew what those were.

Also, it's important to remember you're talking about your app. Apple's app really aren't that reliable. Apple regularly changes and breaks them with no warning. Plus, with these kinds of integrations, you're unhorsing yourself. It's better to keep the user inside your app whenever possible. Don't treat Apple as the primary developer you're trying to integrate with. Treat Apple as your competition.