macOS 26 Launch Constraints

I should add, that using codesign -d -vvvv to interrogate my helper, it doesn't appear that the parent process plist (.coderequirement) is getting embedded in my command-line helper tool. The info.plist IS getting embedded, however.

I’m confused by your overall goal here. What are you trying to do with launch contraints?

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

When building as described above, the helper crashes in such a way (Termination Reason: CODESIGNING 4 Launch Constraint Violation) that suggests I need to apply launch constraints to resolve the problem. I had not previously had launch constraints in my project.

I understand what the symptoms are. I’d like to know what your goal is in applying a launch constraint in the first place. What are you actually trying to constrain? And why?

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

I'm only attempting to apply launch constraints because it seems to be the remedy to the helper/daemon crash. If there is a simpler remedy (like a new build setting I'm missing in XCode 26?) that would be even better.

Mainly, I'm confused as to why building with XCode 26 and linking with macOS 26 would cause a crash with that code signing reason when previously it did not.

it seems to be the remedy to the helper/daemon crash.

That’s unlikely. Launch contraints typically cause things to fail rather than make things work. Hence the constraint.

My advice here is that you remove anything you’ve done with regards launch constraints and then debug the original problem you were seeing. If that’s a crash and you post a crash report, I’d be happy to take a look.

See Posting a Crash Report for advice on how to post a crash report.

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

Sounds good. Here is the crash report:

OK, so you’re dying from a launch constraint violation. That launch constraint can come from two places:

• You can bake a constraint into your executable.
• The code running your daemon can apply a constraint.

I believe you’ve eliminated the first possibility, but it’s a good idea to check that. You can do that using codesign:

% codesign -d -vvv "Desktop/My App.app/Contents/MacOS/com.myCompany.myDaemon"
…
Launch Constraints:
…

You shouldn’t see a Launch Constraints field.

As to the second possibility, there are two things to check:

• Make sure your daemon is signed with the some code-signing identity as the container app.
• Move your app from the desktop to a directory that isn’t protected by MAC. MAC-protected directories — like the desktop, Documents folder, and Downloads folder — cause all sorts of weird behaviour. I generally recommend that you run your app from either the Xcode build directory or /Applications.

For more info about MAC, see On File System Permissions.

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

Thanks for the feedback! No launch constraints in the codesign output, and the codesigning matches between app and daemon. I moved the app to /Applications and the issue persists. Alas, I'm still confused...

If it's relevant, the daemon relies on several frameworks that we also build from the same project. The frameworks are stored in the main app.