Bug filed: FB22189729

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.

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)

Yes, it's using the BundleProgram property.

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.

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.

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

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

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.

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

Looks like someone has already posted an Issue regarding adding high/low water marks for AsyncStream. It will certainly be ideal if that option becomes available. Thanks!

I've been working on reading the data with: DispatchIO.read(fromFileDescriptor: readFD.rawValue, maxLength: whatLength, runningHandlerOn: queue) and also from an instance of DispatchIO like: let channel = DispatchIO(type: .stream, fileDescriptor: readFD.rawValue, queue: queue) { error in ...} // and channel.read(offset: 0, length: 2, queue: queue) { done, data, error in ... } I'm finding that these don't 'see' the data until the process finishes either... can you point out what I'm missing? Many thanks!

Since Subprocess is so shiny and new, do I still use Feedback Assistant, or do I need to do so elsewhere?

In playing with Subprocess, I'm assuming that I'll need to use the custom closure example... Except that the sample code has some errors, particularly, this line: { execution in // <--- it wants three more arguments and: for try await chunk in execution.standardOutput { //<--- Execution doesn't have a member standardOutput Not sure where to go from here... Perhaps return to an earlier methodology?