libswiftCompatibilitySpan.dylib missing in XCode 26.3

The helper is installed using SMAppService.

Is it using the BundleProgram property, so that the system runs the privileged helper tool from within the app bundle?

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

Yes, it's using the BundleProgram property.

OK.

When you run this command, what do you see:

% find YourApp.app -name "libswiftCompatibilitySpan.dylib"
YourApp.app/Contents/Frameworks/libswiftCompatibilitySpan.dylib

libswiftCompatibilitySpan.dylib exists to provide Span support on older systems. AFAICT it’s expected to work on Intel Macs running 13.1 or later:

% vtool -show-build Test817488.app/Contents/Frameworks/libswiftCompatibilitySpan.dylib
Test817488.app/Contents/Frameworks/libswiftCompatibilitySpan.dylib (architecture x86_64):
Load command 10
      cmd LC_BUILD_VERSION
  cmdsize 32
 platform MACOS
    minos 13.1
      sdk 26.2
   ntools 1
     tool LD
  version 1230.1
…

And I tested it here in my office, on both 26.2 (Rosetta) and 13.6.1 (real hardware), and I didn’t have a problem. However, that was from my main app, not from a privileged helper tool, so it’s possible that there’s something specific to privileged helper tools in play here.

My test code is pasted in at the end of this email. If you temporarily add this to your app, does it work on the same Intel Mac?

And with that in place, does your helper tool spontaneously start working?

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

func runTest() {
    print("AppDelegate.testAction(_:)")
    Task {
        do {
            print("will list")
            let result = try await run(.name("ls"), output: .string(limit: 4096))
            print("did list, \(result)")
        } catch {
            print("did not list, \(error)")
        }
    }
}

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)

Including the sample code in the helper

Ah, I think you misunderstood that test. I was suggesting that you temporarily add that code to the app, with some sort of debug UI wired up to call it. That has two benefits:

• If it fails in the app context then there’s something weird going on.
• If it works in the app context, it should cause Xcode to embed libswiftCompatibilitySpan.dylib which might then ‘fix’ your helper tool.

And if that second point is true, it confirms the nature of the problem and suggests a path to a workaround.

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

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.

Cool.

I consider this to be a problem with Xcode’s build system, but it’s an understandable one. Xcode knows that your tool depends on this library — because it adds an import of it — but, being a command-line tool, it doesn’t have anywhere to embed the library. It should embed it in the container app, but it’s clearly not doing that.

I think it’s worth filing a bug against Xcode about that. And if you do, please post your bug number, just for the record.

As to a workaround, there’s a couple of ways to approach that. The first is the obvious one we’ve been discussing here: Add a dummy use of Subprocess within your app. Xcode will embed libswiftCompatibilitySpan.dylib, because it knows that your app needs it, and your tool can pick it up from there

The other option is to embed the library explicitly. This is complicated by the fact that the library exists within a toolchain, so it’s not clear how to reference it [1].

For the moment I recommend that you go with the first option. I’m going to talk to some colleagues to see if we have a specific recommendation for the second one.

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

[1] Because the library ships as part of the toolchain, namely, Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-6.2/macosx/libswiftCompatibilitySpan.dylib.