We did hit strange error lately. After building the product(rather big macos app, C, C++, ObjC, Swift codebase), it runs well on macos 14+. On lower targets we get crash during startup about missing symbol.
Termination Reason: Namespace DYLD, Code 4 Symbol missing
Symbol not found: _$sSa034_makeUniqueAndReserveCapacityIfNotB0yyFyXl_Ts5
Referenced from: <4A1BC342-E608-3A85-A754-5CDB86D5CA16> /Applications/-redacted-
Expected in: /usr/lib/swift/libswiftCore.dylib
(terminated at launch; ignore backtrace)
It seems to be private symbol in swift core library, google shows nothing.
Weakly linking libswiftcore helps, but why such runtime error is there in the first place? What is causing it?
In my experience, most issues like this are caused by one of two things:
Setting your deployment target lower than the minimum supported by your tools.
Building different chunks of your code with different deployment targets.
Recent versions of Xcode support back to macOS 10.13 [1], which rules out the first possibility.
The second possibility happens when one or more of the Mach-O object files (.o) that were linked together to create the Mach-O image were built with a higher deployment target that the image itself. I most commonly see this when static libraries are in play.
Sometimes you can figure this out by carefully reviewing your build settings. Failing that, there’s two paths forward:
Review the deployment target of every .o files that was linked into the Mach-O image. Remember to dig inside static libraries. Use vtool with the -show-build subcommand to get the deployment target.
In many cases you can use the -why_live option as a shortcut to see where the reference came from. See the discussion at the bottom of Determining Why a Symbol is Referenced.
ps I’m using the terminology from An Apple Library Primer. If you’re gonna work at this level, I strongly recommend that you review that post.
Finally, there is a third possible cause here:
A bug in the compiler or libraries.
I’ve definitely seen this. It’s less common than the other two possibilities, so my initial advice is that you rule those out before heading down this third path.
Share and Enjoy
Quinn “The Eskimo!” @ DTS @ Apple
[1] Although Xcode 26 beta raises this to macOS 11. I highly recommend that you bookmark Developer > Support > Xcode.
I have a bit of evidence suggesting this third cause could be the issue, the feedback (FB19040850) we filed a couple of weeks ago:
Symbol references in `if #available(iOS 16, *) {…}` blocks crash program at launch: system frameworks are no longer weak-linked by default
Swift code referencing conditionally available NSString constants inside guarded by if #available(iOS 16, *) checks stopped working in the latest Xcode 26 beta. Expecting the app to launch without crashing in these cases.
Consider this simple iOS app (also attached as Xcode project):
import AVFoundation
import MetricKit
import StoreKit
import SwiftUI
@main
struct SymbolNotFoundApp: App {
var strings: [String] = []
init() {
// Comment out these lines to avoid the crash:
if #available(iOS 16.0, *) { strings.append(AVURLAssetHTTPUserAgentKey) }
if #available(iOS 16.0, *) { strings.append(MXErrorDomain) }
if #available(iOS 16.1, *) { strings.append(SKStoreProductParameterAdNetworkSourceIdentifier) }
}
var body: some Scene {
WindowGroup {
Text(strings.isEmpty ? "No strings." : strings.joined(separator: "\n")).padding()
}
}
}
Build the attached project with Xcode 16.4 and run on iOS 15.5 simulator or device: the app launches displaying the message "No strings." as expected.
Then repeat the same with Xcode 26 beta 4 and iOS 15.5: the app now crashes at launch with the following error:
Symbol not found: _AVURLAssetHTTPUserAgentKey
Referenced from:
/Users/<me>/Library/Developer/CoreSimulator/Devices/<uuid>/data/Containers/Bundle/Application/<uuid>/Xcode26-iOS15-AVURLAssetHTTPUserAgentKe
.app/Xcode26-iOS15-AVURLAssetHTTPUserAgentKey
Expected in: /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS
15.5.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/AVFoundation.framework/AVFoundation
With Xcode 16.4 and prior, system frameworks would get automatically linked weakly, causing conditionally available symbol references to only be looked up by dyld when needed. But when compiled with the latest beta SDK, the system frameworks are suddenly linked strongly, as seen when comparing the dyld_info output of the app binary:
The workaround is to mark the frameworks as "optional" in the "Link Binary With Libraries" phase, but this shouldn't be required by the developer, AFAICT.
the feedback (FB19040850) we filed a couple of weeks ago
Oh, thanks for that.
Looking at the bug it seems to be ‘real’, that is, something in the toolchain rather than something in your project.
Your bug was filed against Xcode 26.0b4. @Juraj, are you also seeing this on the beta? I’d assumed that you were on a production Xcode, but looking over your original post I don’t see any evidence for that assumption.