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'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.

Sounds good. Here is the crash report: com.myCompany.myDaemon-2025-09-15-081339.txt

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.

The problem ended up being solved by calling: sfltool resetbtm in Terminal, followed of course by a restart on each affected machine. Interesting that it occurred across several machines all running macOS 13 and 14 right when we updated to Xcode 26. It does seem like the system will occasionally get upset with big changes to the app through the development cycle.

Yes, it's using the BundleProgram property.

The find command returns nothing when the app is built with XCode 26.3 or XCode 26.2. Is there a build setting that ensures that libswiftCompatibilitySpan.dylib gets included? I've tried copying it in build phases, but that crashes the main app. I do have "Always Embed Swift Standard Libraries" set to yes in the main app. Including the sample code in the helper (NB: the helper tool doesn't have an app delegate - it's a command line tool) also doesn't resolve the crash. If it's helpful, here's the relevant piece of the crash log from the helper: Termination Reason: Namespace DYLD, Code 1 Library missing Library not loaded: @rpath/libswiftCompatibilitySpan.dylib Referenced from: <91AD8720-25FD-3ABB-B10A-6A7630E7BA48> /Users/USER/Library/Developer/Xcode/DerivedData/MyApp-hapnwyzmnoqmoybwzlybjoupeflc/Build/Products/Debug/MyApp.app/Contents/MacOS/com.micromat.TTDaemon Reason: tried: '/usr/lib/swift/libswiftCompatibilitySpan.dylib' (no such file, not in dyld cache), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/swift/libswiftCompatibilitySpan.dylib' (no such file), '/Users/myUser/Library/Developer/Xcode/DerivedData/MyApp-hapnwyzmnoqmoybwzlybjoupeflc/Build/Products/Debug/PackageFrameworks/libswiftCompatibilitySpan.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/myUser/Library/Developer/Xcode/DerivedData/MyApp-hapnwyzmnoqmoybwzlybjoupeflc/Build/Products/Debug/PackageFrameworks/libswiftCompatibilitySpan.dylib' (no such file), '/Users/myUser/Library/Developer/Xcode/DerivedData/MyApp-hapnwyzmnoqmoybwzlybjoupeflc/Build/Products/Debug/MyApp.app/Contents/Fra (terminated at launch; ignore backtrace)

Thanks for the clarification! Adding the test code to the main app does indeed embed libswiftCompatibilitySpan.dylib to the main app, and then the helper runs as expected.

Bug filed: FB22189729