To test my suspicion that this is an Xcode issue and not macOS 15 issue, I used Swift Package Manager to built a small executable instead of building it with Xcode. The complete software (using the new Span API) is this: import Foundation @main struct App { static func main() { let data = Data([1, 2, 3, 4, 5]) let span = data.span print(span[2]) } } using this Package.swift file // swift-tools-version: 6.2 import PackageDescription let package = Package( name: "span-compat-test", platforms: [.macOS(.v13)], targets: [.executableTarget(name: "span-compat-test")] ) I make an executable by running swift build -c release on macOS 26 using Apple Swift version 6.2.1 (swift-6.2.1-RELEASE). The resulting executable runs on macOS 26, macOS 15, and macOS 14. I have not tested older OS versions. So, SwiftPM is able to compile the executable in a way that runs on older OS versions while in Xcode I currently require a manual workaround.

I figured out a workaround: Add a new “Copy Files” build phase to the target with the destination “Frameworks” with the following file /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-6.2/macosx/libswiftCompatibilitySpan.dylib That is, copying the libswiftCompatibilitySpan.dylib file manually into the “Frameworks” directory of the bundle. The bundle now loads on older OS versions like macOS 15. However, this workaround is not a good solution as it requires me to manually find the libswiftCompatibilitySpan.dylib file and ensure to keep its path updated in the Xcode project settings each time the toolchain is updated. Ideally, Xcode would recognize that libswiftCompatibilitySpan.dylib is linked using rpath and include the file in the “Frameworks” directory automatically. Maybe there is a build setting that I need to enable that would do this, but I could not find anything.

Thanks for looking into this. When you say “as far as I know this issue was fixed in Xcode, not in macOS”, do you mean I should report a bug for macOS, not Xcode? A bugfix update for macOS 15 would not help me deploy my software to older OS versions since I cannot rely on users of older OS versions to update to the bugfixed OS version in a timely manner. As far as I can tell, Xcode is not including the comparability dylib in the compilation of the bundle. Thus, the bug would need to be fixed in Xcode.

Based on your description, you are encountering an issue with loading the library and deploying it into macOS versions 15? Correct. Can you confirm that when you deploy the app built in Xcode 26.2 to macOS 15, you still encounter this bug? That is the case. I sm compiling with Xcode 26.2 using macOS 26.2 (25C57) SDK (Built-in) targeting macOS 12 and later. The error occurs on macOS 15.7.3 but not on macOS 26. I suspect this is because macOS provides the Span API natively and thus does not need to access the backdeployment dylib, unlike macOS 15 where this API is not available natively. Talking to people working on Swift, they interpreted this to be an Xcode issue, stating: Xcode should (somehow) bundle libswiftCompatibilitySpan with it, but it doesn’t, leading to the failure on macOS 15.x.

I have the same issue. My code looks like this: let predicate = CNContact.predicateForContacts(matchingEmailAddress: emailAddress) let keysToFetch = [CNContactImageDataKey, CNContactThumbnailImageDataKey] as [CNKeyDescriptor] if let contacts = try? CNContactStore().unifiedContacts(matching: predicate, keysToFetch: keysToFetch) { // ... } where I get the following errors: Attempted to register account monitor for types client is not authorized to access: {( "com.apple.account.CardDAV", "com.apple.account.Exchange", "com.apple.account.LDAP" )} CNAccountCollectionUpdateWatcher 0x600004280e80: Store registration failed: Error Domain=com.apple.accounts Code=7 "(null)" CNAccountCollectionUpdateWatcher 0x600004280e80: Update event received, but store registration failed. This event will be handled, but the behavior is undefined. Attempt to read notes by an unentitled app on macOS 14.5 (23F79). I can ignore the errors in the console, which is not ideal, but my main issue with these errors is that they trigger the “All Runtime Issues” breakpoint.