Search results for

build disappears

50,281 results found

Post

Replies

Boosts

Views

Activity

Library not loaded: @rpath/libswiftCompatibilitySpan.dylib – Building bundle target
I am building a bundle target for macOS 12 and later using Xcode. The bundle is not a standalone app, but a plug-in that is loaded by a host app. The code is written in Swift and uses the new Span API which is available in the OS-provided standard library in macOS 26 and backdeploys to macOS 10.14.4+. Xcode should instruct the linker to include libswiftCompatibilitySpan.dylib in the compiled bundle to provide this backdeployment, but that does not happen. SwiftPM does this additional linking by adding an rpath. When trying to load the bundle using the NSBundle.loadAndReturnError() API, I get the following error on macOS 15 (and no error on macOS 26): Error Domain=NSCocoaErrorDomain Code=3588 dlopen(.../MyBundle.someBundle/Contents/MacOS/MyBundle, 0x0109): Library not loaded: @rpath/libswiftCompatibilitySpan.dylib Referenced from: .../MyBundle.someBundle/Contents/MacOS/MyBundle Reason: tried: '/usr/lib/swift/libswiftCompatibilitySpan.dylib' (no such file, not in dyld cache), '/System/Volumes/Preboot/
Topic: Developer Tools & Services SubTopic: Xcode Tags:
8
0
219
12h
Reply to Library not loaded: @rpath/libswiftCompatibilitySpan.dylib – Building bundle target
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.
Topic: Developer Tools & Services SubTopic: Xcode Tags:
12h
Build Submitted Successfully but Not Showing in TestFlight. Submit stack
Hello everyone, I successfully submitted my iOS app build to App Store Connect via EAS(expo.dev). The submission logs confirm successful upload, but the build is not visible in App store connect TestFlight → Builds after several hours. Submission was successful according to logs: Successfully uploaded package to App Store Connect and The app has been submitted successfully. Has anyone experienced a problem with this? Can I get some information? Thank you.
Topic: App Store Distribution & Marketing SubTopic: TestFlight Tags:
1
0
51
12h
Reply to Xcode Cloud builds stuck at App Store Connect
Looks like an issue with App Uploads on App Store Connect was finally acknowledged on https://developer.apple.com/system-status/. We recently migrated to using exclusively Xcode Cloud, so I completely agree that instances like this happen WAY too often with no communication from Apple and are showstoppers for our process. While asking developers to verify that their projects work used to be accurate when dealing with local issues, Xcode Cloud seems to just give out at random times with no indication of what's wrong. These issues seem to solely lie with Apple's implementation of a cloud based build service, which is magnified by a serious lack of communication from Apple during these outages.
Topic: Developer Tools & Services SubTopic: Xcode Cloud Tags:
11h
Reply to Library not loaded: @rpath/libswiftCompatibilitySpan.dylib – Building bundle target
Thank you for your post and the valuable workaround information provided. Very interesting! Managing dynamic libraries and ensuring compatibility across various macOS versions can indeed be a complex task. The manual workaround you have implemented is highly intelligent and an effective approach when dealing with missing runtime libraries on older systems, but should not be missing in macOS as far as I know. However, automating this process would undoubtedly enhance maintainability. In my opinion, it would be beneficial to have a bug report indicating the issue in macOS 15. Instead of hardcoding the path to, you can utilize to dynamically locate it. This approach can make your build script more resilient to changes in Xcode toolchain paths. Modify your “Copy Files” build phase to include a script that utilizes, ensuring its adaptability. Given your belief that Xcode should handle this better, and I concur, consider submitting feedback to Apple on your bug report, even if the target is macOS
Topic: Developer Tools & Services SubTopic: Xcode Tags:
13h