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?

Thanks! I'm afraid I still need to support Ventura, so I can't adopt Swift 6 just yet. I have a tool that verifies volumes using diskutil.

Thanks for the quick response. Feedback filed, number: FB16924007.

Sorry, I didn't mean to leave this hanging. It turned out that the problem was the location of the application. It is an accessory app, so we were storing it outside of the Applications folder. Installing it in the Applications folder 'solved' the issue. You can reproduce in Monterey by moving an app containing widgets to somewhere like Application Support. It appears that later versions of macOS can discover widgets outside of Applications, while earlier ones cannot. Thanks!

I think I figured it out. In any event, the helper is no longer crashing. I added @executable_path/../Frameworks to Runpath Search Paths in the helper's build settings. Thanks!