Entitlement to open helper app inside bundle?

I include a faceless helper app inside my main app's bundle (inside the SharedSupport directory). The first time I go to launch it using NSWorkspace, the system presents a dialog:


"You are opening the application “HelperApp” for the first time. Are you sure you want to open this application?

The application is in a folder named “SharedSupport”. To see the application in the Finder without opening it, click Show Application."


The user can choose cancel and the helper will not be launched.


This is a bit annoying and confusing for the user, and a bit of an implementation leak. Is there any way I can include a permission in the entitlements for my main app, or some other way to bypass the dialog?

Replies

inside the SharedSupport directory

I don’t think this affects your main issue but, just FYI,

SharedSupport
is not the right place for nested code. See the Nested Code section of Technote 2206 macOS Code Signing In Depth for more on this.

Is there any way I can include a permission in the entitlements for my main app, or some other way to bypass the dialog?

What’s the lifecycle of your helper app? My standard approach for this is one of the following, depending on that lifecycle:

  • If I want the helper app to run after my app has quit, I use

    SMLoginItemSetEnabled
    .
  • If I want the helper app to run while my app is running, I use an XPC Service.

Neither of these require a user approval to launch.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"
I tried using SMLoginItemSetEnabled, but found that it didn't actually launch the copy of my helper inside the running copy of my app, but rather launched an older copy inside some archived copy of the main app. So unless I change my helper's bundle ID every time I update the helper, this doesn't seem like a reliable solution.

I tried using SMLoginItemSetEnabled, but found that it didn't
actually launch the copy of my helper inside the running copy of my
app, but rather launched an older copy inside some archived copy of
the main app.

That is, indeed, an annoying habit of this API, one that’s definitely worth filing a bug about. Please post your bug number, just for the record.

In most cases this bug doesn’t affect users in the field because they only have one copy of your app installed. This is especially likely if you distribute your app via the Mac App Store.

Still, f you want to guard against this you should have your Service Management login item publish an XPC service that returns its version number. That way you can detect if you’re running an old version and guide the user appropriately.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Thanks for the confirmation, Quinn. Bug filed, FB8892495. For now I will just increment a number at the end of my login item's bundle ID whenever I update it, which isn't that often.