HI, I have a Swift UI app in the mac appstore in the upcoming release we have made lots of changes and it is working fine in debug mode but in production with testflight or direct distribution we are getting the following crash while working in the app. this is happening in the rendering phase. Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libswiftCore.dylib 0x19546f270 swift_unknownObjectRetain + 44 1 libswiftCore.dylib 0x1954bb09c swift_cvw_initWithCopyImpl(swift::OpaqueValue*, swift::OpaqueValue*, swift::TargetMetadata<swift::InProcess> const*) + 280 2 libswiftCore.dylib 0x1958f685c initializeWithCopy for ClosedRange<>.Index + 212 3 VirtualProg 0x104d73958 <deduplicated_symbol> + 56 How can i debug to find out what is causing the issue and fix it?. thanks in advance

Is anyone have this problem on xcode 26 ? Undefined symbol: _swift_FORCE_LOAD$_swiftCompatibility50 Undefined symbol: _swift_FORCE_LOAD$_swiftCompatibility51 Undefined symbol: _swift_FORCE_LOAD$_swiftCompatibility56 Undefined symbol: _swift_FORCE_LOAD$_swiftCompatibilityConcurrency Undefined symbol: _swift_FORCE_LOAD$_swiftCompatibilityDynamicReplacements

Hi team: I recently update to Xcode 26.4, and I encountered crash when running to < iOS 26.4 both for physical device and Simulator with this log: dyld[1257]: Symbol not found: _$s9MetricKit10mxSignpost_3dso3log4name10signpostID__ySo03os_H7_type_ta_SVSo03OS_j1_F0Cs12StaticStringV0J0010OSSignpostI0VALSays7CVarArg_pGtF Referenced from: <164CCEB0-E1F8-3CE2-A934-2096C19C0A9A> /private/var/containers/Bundle/Application/EA709A68-F76F-4D97-85C6-B71D61D68389/xxx.app/xxx.debug.dylib Expected in: <9E5EC9BB-5828-329C-A2BC-038B67060298> /System/Library/Frameworks/MetricKit.framework/MetricKit Symbol not found: _$s9MetricKit10mxSignpost_3dso3log4name10signpostID__ySo03os_H7_type_ta_SVSo03OS_j1_F0Cs12StaticStringV0J0010OSSignpostI0VALSays7CVarArg_pGtF Referenced from: <164CCEB0-E1F8-3CE2-A934-2096C19C0A9A>x /private/var/containers/Bundle/Application/EA709A68-F76F-4D97-85C6-B71D61D68389/xxx.app/xxx.debug.dylib Expected in: <9E5EC9BB-5828-329C-A2BC-038B67060298> /System/Library/Frameworks/MetricKit.framework/MetricKit dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libLogRedirect.dylib:/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/usr/lib/libViewDebuggerSupport.dylib but iOS 26.4 works well. Env: Xcode: 26.4 Simulator/Physical Device: < 26.4 macOS: 26.3 Thanks for giving any help.

It didn't happen with Xcode 16.2 that I used before, but after updating to 16.3, when I build the app, the following error is output to the console and the app doesn't run. dyld[2150]: Symbol not found: ___cxa_current_primary_exception Referenced from: <6B00A4F2-B208-3FDB-BA38-B7095AF0034A> /private/var/containers/Bundle/Application/B590DB18-9C66-4C9E-8330-104943419E60/Mubeat DEV.app/Mubeat DEV.debug.dylib Expected in: <7F51CB08-A0CA-386E-BB62-4B8BFB0CED9F> /usr/lib/libc++.1.dylib Symbol not found: ___cxa_current_primary_exception Referenced from: <6B00A4F2-B208-3FDB-BA38-B7095AF0034A> /private/var/containers/Bundle/Application/B590DB18-9C66-4C9E-8330-104943419E60/Mubeat DEV.app/Mubeat DEV.debug.dylib Expected in: <7F51CB08-A0CA-386E-BB62-4B8BFB0CED9F> /usr/lib/libc++.1.dylib dyld config: DYLD_LIBRARY_PATH=/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/usr/lib/libBacktraceRecording.dylib:/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/Developer/Library/PrivateFrameworks/DTDDISupport.framework/libViewDebuggerSupport.dylib After looking for another solution, I found a way to remove the -Objc option in Other Linker Flags, but this method only works on iOS 18.4 and doesn't work on other versions. Is there another solution?

I'm struggling to build a driver for iPadOS in a particular project configuration. If I put the driver code and dext target into the same Xcode project which contains the iPad app, all is well. This is the way the Xcode driver template does it. However, I'd like to build and debug the dext on macOS, while eventually deploying on iPadOS. So I put the dext into a different project, which has a macOS target, a minimal iPadOS target and a DriverKit target. I made a workspace which contains both projects. I dragged the macOS project into the iPadOS project so that I can refer to the products of the macOS project (specifically, its driver target) as a dependency of the iPadOS target. Note that the main iPad app target depends on the driver target. So the workspace organization looks like this: Workspace iPad project main iPad app target (depends on driver) test project reference test project test macOS/iPad app target DriverKit dext target When I build the iPadOS target, it builds the dependent driver target in the macOS project, but it fails to link because Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a is not found. If I just build the driver target directly in Xcode, there is no such complaint. I looked closely at the build logs, and I see for the failed link, there are these two linker flags set which are not set in the successful case -debug_variant -fprofile-instr-generate I can't seem to control the generation of this flag. I tried turning off the Profile switch in the Scheme editor for the driver, but is makes no difference. When I directly build the driver target, no -fprofile-instr-generate is set and it compiles and links. When i build the driver as a dependency of another target, -fprofile-instr-generate is passed to the linker, which fails. The obvious workaround is to put the driver source code into a separate driver target in the iPadOS project, but I'd rather have just one DriverKit driver for both platforms, with a few settings (such as bundle ID) controlled by a configuration file. Has anyone else encountered this problem, and know of a workaround?

Hi, I'm investigating what looks like possibly nondeterministic behavior when linking large iOS app binaries. I do not have a concise reproduction of the issue yet, but am trying to hunt down possible leads. In particular, the problem appears to surface when invoking clang to link a binary and the resulting order of the 'branch island' instructions appears to be random each time the binary is linked (as shown by the link map output). I was wondering if anyone with insight into the linker's current implementation could shed light on whether that is expected, and if there is anything that can be done to prevent it. FWIW, it seems like it might be size-dependent as smaller app binaries don't appear to exhibit the same behavior. I'd be glad to share more specifics and hopefully a reproduction if I can ever find one eventually. Some environment info (Xcode 16.4 toolchain): clang -v: Apple clang version 17.0.0 (clang-1700.0.13.5) Target: arm64-apple-darwin24.6.0 Thread model: posix InstalledDir: /Applications/Xcode-16.4.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin ld -v: @(#)PROGRAM:ld PROJECT:ld-1167.5 BUILD 01:45:05 Apr 30 2025 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em will use ld-classic for: armv6 armv7 armv7s i386 armv6m armv7k armv7m armv7em LTO support using: LLVM version 17.0.0 (static support for 29, runtime is 29) TAPI support using: Apple TAPI version 17.0.0 (tapi-1700.0.3.5)

Calling dlopen then dlclose causes an increase in the amount of memory used by the program. If I create a loop that calls dlopen / dlclose repeatedly on the same dynamic library, memory usage increases continuously. Is this a bug, or am I using dlopen / dlclose incorrectly? I can reproduce this by modifying the sample code in the Apple Developer docs Creating Dynamic Libraries. If I modify Runtime.c, changing the line void *lib_handle = dlopen(lib_name, RTLD_NOW); to add the infinite loop, as below: void *lib_handle = dlopen(lib_name, RTLD_NOW); for (int ii = 0; ; ++ii) { printf("loop %i\n", ii); int close_err = dlclose(lib_handle); printf("close error: %i\n", close_err); printf("dlopen(%s, RTLD_NOW)\n", lib_name); lib_handle = dlopen(lib_name, RTLD_NOW); } then opening and closing the dynamic library will succeed, but memory usage (as reported by top) will rapidly increase. I'm running on x86_64 macOS 13.6.6. Full code for the modified Runtime.c is attached, the rest of the code is available in the Apple Developer docs. Any suggestions? Many thanks, Chris Runtime.c

Dear Apple engineers: My previous project was successfully compiled using Xcode 16.2. Now, I need to adapt it to Xcode 26. I know that the linker in Xcode 26 has undergone significant changes. So, in the 'Other Linker Flags' configuration of the Build Settings in the project engineering of Xcode 26.2, I deleted '-ld64' and added '-Xlinker -dead_strip -Xlinker -dead_strip -allow_dead_duplicates' to adapt to the new linker of Xcode 26. After the modification, when I compiled my project engineering using Xcode 26.2 compiler, I encountered a new linker error. The error log is attached. Regarding this error, how should we solve it? Thank you. XCode26.2BuildErrorLog.txt

log

I'm working on a command line tool, and trying to make it as fast as possible. I ran it under instruments' processor trace (really cool tool by the way, thanks for that) and found that the majority of the time it is taking to run, is actually spent in dyld, specifically dyld4::prepare(dyld4::APIs&, mach_o::Header const*). Out of a total run time of 1.27ms my code only takes 34.17μs or about 2.7%, that's a LOT of overhead! I re-ran my binary with the dyld activity instrument added to the mix, and it showed that the biggest known chunk of time that dyld spends during process startup is in "Run static initializer" from libSystem, though the majority of the time spent by dyld is unaccounted for and left labelled generically as "Launch Executable". Obviously I can't modify libSystem on my users' systems so is there anything I can do to reduce this overhead? Maybe some way to promise that I won't use the Obj-C runtime so that doesn't need setting-up or something?

In our app, we implement a document picker using FilePickerManager+available.m, selecting different APIs based on the iOS version: if (@available(iOS 14.0, *)) { NSMutableArray<UTType *> *contentTypes = [NSMutableArray array]; for (NSString *uti in documentTypes) { UTType *type = [UTType typeWithIdentifier:uti]; if (type) { [contentTypes addObject:type]; NSLog(@"iOS 14+ Adding type: %@", uti); } else { NSLog(@"Warning: Unable to create UTI: %@", uti); } } UIDocumentPickerViewController *documentPicker = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypes]; documentPicker.delegate = self; documentPicker.allowsMultipleSelection = NO; [self.presentingViewController presentViewController:documentPicker animated:YES completion:nil]; } However, we've observed inconsistent symbol reference types to UTType in the final linked binaries: One build results in a strong reference to UTType. Another demo project (with seemingly identical code and build settings) results in a weak reference. Both object files (.o) show undefined references to UTType symbols (e.g., UTTypeCreatePreferredIdentifierForTag), yet the final linked binaries differ in how these symbols are resolved. Impact of the Issue This inconsistency causes problems on iOS 14.0+ devices: Strong reference version: Fails to launch on devices where the UniformTypeIdentifiers framework is not present (e.g., certain older iOS 14.x devices), due to link-time failure. Weak reference version: Launches successfully but crashes at runtime when attempting to call UTType methods, because the implementation cannot be found. Our Analysis Using nm -u, both versions show an undefined symbol: U _UTTypeCreatePreferredIdentifierForTag However, in the final binaries: One shows: T _UTTypeCreatePreferredIdentifierForTag (strong) The other shows: W _UTTypeCreatePreferredIdentifierForTag (weak) Both projects link against the framework identically in their build logs: -framework UniformTypeIdentifiers (no -weak_framework flag is used in either case). Questions Why do identical source code and linker flags result in different symbol reference strengths (T vs W) for the same framework? Are there specific compiler or linker behaviors (e.g., deployment target, SDK version, module imports, or bitcode settings) that influence whether symbols from UniformTypeIdentifiers are treated as strong or weak? What is the recommended best practice to ensure consistent symbol referencing when using newer APIs like UTType, especially when supporting older OS versions? We aim to understand this behavior to guarantee stable operation across all supported iOS versions—avoiding both launch failures and runtime crashes caused by inconsistent symbol linking. Any insights or guidance from the community or Apple engineers would be greatly appreciated! Let me know if you'd like a shorter version or want to include additional build environment details (Xcode version, deployment target, etc.)!

In our app, we implement a document picker using FilePickerManager+available.m, selecting different APIs based on the iOS version: if (@available(iOS 14.0, *)) { NSMutableArray<UTType *> *contentTypes = [NSMutableArray array]; for (NSString *uti in documentTypes) { UTType *type = [UTType typeWithIdentifier:uti]; if (type) { [contentTypes addObject:type]; NSLog(@"iOS 14+ Adding type: %@", uti); } else { NSLog(@"Warning: Unable to create UTI: %@", uti); } } UIDocumentPickerViewController *documentPicker = [[UIDocumentPickerViewController alloc] initForOpeningContentTypes:contentTypes]; documentPicker.delegate = self; documentPicker.allowsMultipleSelection = NO; [self.presentingViewController presentViewController:documentPicker animated:YES completion:nil]; } However, we've observed inconsistent symbol reference types to UTType in the final linked binaries: One build results in a strong reference to UTType. Another demo project (with seemingly identical code and build settings) results in a weak reference. Both object files (.o) show undefined references to UTType symbols (e.g., UTTypeCreatePreferredIdentifierForTag), yet the final linked binaries differ in how these symbols are resolved. Impact of the Issue This inconsistency causes problems on iOS 14.0+ devices: Strong reference version: Fails to launch on devices where the UniformTypeIdentifiers framework is not present (e.g., certain older iOS 14.x devices), due to link-time failure. Weak reference version: Launches successfully but crashes at runtime when attempting to call UTType methods, because the implementation cannot be found. Our Analysis Using nm -u, both versions show an undefined symbol: U _UTTypeCreatePreferredIdentifierForTag However, in the final binaries: One shows: T _UTTypeCreatePreferredIdentifierForTag (strong) The other shows: W _UTTypeCreatePreferredIdentifierForTag (weak) Both projects link against the framework identically in their build logs: -framework UniformTypeIdentifiers (no -weak_framework flag is used in either case). Questions Why do identical source code and linker flags result in different symbol reference strengths (T vs W) for the same framework? Are there specific compiler or linker behaviors (e.g., deployment target, SDK version, module imports, or bitcode settings) that influence whether symbols from UniformTypeIdentifiers are treated as strong or weak? What is the recommended best practice to ensure consistent symbol referencing when using newer APIs like UTType, especially when supporting older OS versions? We aim to understand this behavior to guarantee stable operation across all supported iOS versions—avoiding both launch failures and runtime crashes caused by inconsistent symbol linking. Any insights or guidance from the community or Apple engineers would be greatly appreciated! Let me know if you'd like a shorter version or want to include additional build environment details (Xcode version, deployment target, etc.)!

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: <CE92806C-94B7-367E-895D-EF6DF66C7FC2> .../MyBundle.someBundle/Contents/MacOS/MyBundle 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), '/private/Frameworks/libswiftCompatibilitySpan.dylib' (no such file), '.../MyBundle.someBundle/Contents/MacOS/../Frameworks/libswiftCompatibilitySpan.dylib' (no such file), '/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), '/private/Frameworks/libswiftCompatibilitySpan.dylib' (no such file), '.../MyBundle.someBundle/Contents/MacOS/../Frameworks/libswiftCompatibilitySpan.dylib' (no such file)" UserInfo={NSLocalizedFailureReason=The bundle couldn’t be loaded., NSLocalizedRecoverySuggestion=Try reinstalling the bundle., NSFilePath=.../MyBundle.someBundle/Contents/MacOS/MyBundle, NSDebugDescription=dlopen(.../MyBundle.someBundle/Contents/MacOS/MyBundle, 0x0109): Library not loaded: @rpath/libswiftCompatibilitySpan.dylib Referenced from: <CE92806C-94B7-367E-895D-EF6DF66C7FC2> .../MyBundle.someBundle/Contents/MacOS/MyBundle 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), '/private/Frameworks/libswiftCompatibilitySpan.dylib' (no such file), '.../MyBundle.someBundle/Contents/MacOS/../Frameworks/libswiftCompatibilitySpan.dylib' (no such file), '/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), '/private/Frameworks/libswiftCompatibilitySpan.dylib' (no such file), '.../MyBundle.someBundle/Contents/MacOS/../Frameworks/libswiftCompatibilitySpan.dylib' (no such file), NSBundlePath=.../MyBundle.someBundle, NSLocalizedDescription=The bundle “MyBundle” couldn’t be loaded.} My setup: Xcode 26.2 macOS 26.2 (25C57) SDK (Built-in)

What is the recommended approach for distributing an XCFramework that uses common third-party dependencies (like Google Maps) when client apps may also use the same dependencies, resulting in duplicate symbol conflicts? I'm developing a closed-source SDK distributed as an XCFramework. My SDK internally uses Google Maps for mapping functionality. However, when clients integrate my XCFramework into their apps that also use Google Maps, we encounter duplicate symbol errors. What I've Tried: Static vs Dynamic Linking: Both approaches result in conflicts Static linking: Google Maps symbols compiled into my binary Dynamic linking: GoogleMaps.framework bundled with my XCFramework Build Configuration: Set "Build Libraries for Distribution" = YES Tried various linking strategies Architecture Changes: Used @implementation_only import Wrapped code with #if canImport(GoogleMaps) However, the dependencies still get linked at build time

Hi, I have an iOS project with the following app targets: main iOS application a notification service extension 5 static libs containing some swift files with public methods 1 dynamic framework with above static libs as dependencies. The framework only contains 2 files - a default .h file and 1 .exp file. This exports file contains mangled-names of all the public methods that are exposed by the 5 static libs present as framework's dependencies. I obtained these symbols using the nm command for each static lib. The main iOS app target has 2 dependencies - the framework and the notification extension. The notification extension only depends on the framework. This setup works perfectly fine. I wanted to understand: If using the exports file is the only way to make this setup work? If not, what else can I do? What way does Apple recommend? According to my requirements, I only need at-most 2-3 functions to be exposed by the framework - thus using a exports file just for that seems to bug me. Thank you.

GCC's shared library constructor technique has ceased working with the tool chain provided with XCode 16.4 and XCode 26. This is the GCC attribute: __attribute__((constructor)) Example use: void aConstructor(void) __attribute__((constructor)); void aConstructor(void) { printf("Called aConstructor\n"); } In our case aConstructor() was not called.

I want to create a dynamic library for my iOS project, which would be loaded at runtime. In Xcode, there are templates available for creating a static/dynamic lib for MacOS. But under the iOS tab, there is only a "static library" template. So, I used the "static library" template and in its build settings I changed the Mach-O type to "dynamic library". Now after building it, I use the file command on the generated file and it tells me it is a dynamic lib. But the generated file still has .a extension, which is usually for static libs. I'm aware we can tell Xcode in build settings to change the .a extension to something else, say .dylib but this seems like a hacky way to create a dynamic library. What is the correct way? I am aware that standalone dylibs are not supported on iOS, and we need to wrap them in a framework. For my use case, the framework will literally be a wrapper, it won't have any source files of its own. It should only contain the dynamic lib generated from some independent codebase. I am not sure how to place the dylib in the framework.

I got several reports about our TestFlight app crashing unconditionally on 2 devices (iOS 18.1 and iOS 18.3.1) on app start with the following reason: Termination Reason: DYLD 4 Symbol missing Symbol not found: _$sScIsE4next7ElementQzSgyYa7FailureQzYKF (terminated at launch; ignore backtrace) The symbol in question demangles to (extension in Swift):Swift.AsyncIteratorProtocol.next() async throws(A.Failure) -> A.Element? Our deploy target is iOS 18.0, this symbol was introduced in Swift 6.0, we're using latest Xcode 16 now - everything should be working, but for some reason aren't. Since this symbol is quite rarely used directly, I was able to pinpoint the exact place in code related to it. Few days ago I added the following code to our app library (details omitted): public struct AsyncRecoveringStream<Base: AsyncSequence>: AsyncSequence { ... public struct AsyncIterator: AsyncIteratorProtocol { ... public mutating func next(isolation actor: isolated (any Actor)? = #isolation) async throws(Failure) -> Element? { ... } } } I tried to switch to Xcode 26 - it was still crashing on affected phone. Then I changed next(isolation:) to its older version, next(): public mutating func next() async throws(Failure) -> Element? And there crashes are gone. However, this change is a somewhat problematic, since I either have to lower Swift version of our library from 6 to 5 and we loose concurrency checks and typed throws or I'm loosing tests due to Swift compiler crash. Performance is also affected, but it's not that critical for our case. Why is this crash happening? How can I solve this problem or elegantly work around it? Thank you! 2025-10-09_17-13-31.7885_+0100-23e00e377f9d43422558d069818879042d4c5c2e.crash

LLVM Linker Crash on ARM64 with bfloat16 Symbols (Xcode 17.0.0) We're encountering a critical linker crash in Xcode 17.0.0 (clang-1700.4.4.1) on macOS 15.1.0 (Darwin 25.1.0) with Apple Silicon M3 Max when linking a pybind11 C++ extension against the MLX framework (v0.30.1). The linker consistently crashes with LLVM ERROR: No way to correctly truncate anything but float to bfloat during the linking phase, even though our code uses only integer types (int64, uint32) for BPE tokenization and never directly references bfloat16 types. Error Details: [100%] Linking CXX shared module _metal_trainer.cpython-312-darwin.so LLVM ERROR: No way to correctly truncate anything but float to bfloat clang++: error: unable to execute command: Abort trap: 6 clang++: error: linker command failed due to signal (use -v to see invocation) Reproduction: Install MLX framework: pip install mlx (any version with bfloat16 support) Create a minimal pybind11 extension that links against MLX: Compiler: AppleClang 17.0.0.17000404 Target: arm64-apple-darwin25.1.0 Flags: -std=c++17 -O2 -march=native Link against: libmlx.dylib (contains bfloat16 symbols) Run: cmake .. && make Linker crashes during final linking phase Root Cause: The LLVM ARM64 backend in Xcode 17.0.0 has a code generation bug when processing bfloat16 truncation operations during link-time. The crash occurs when the linker processes bfloat16 symbols from libmlx.dylib, regardless of whether the application code uses them. The error originates from LLVM's type legalization pass attempting to truncate bfloat16 values, but the ARM64 backend lacks a valid code path for this operation. Workarounds Attempted (all failed): Disabling LTO: INTERPROCEDURAL_OPTIMIZATION FALSE Linker flags: -Wl,-no_compact_unwind, -fno-lto Runtime symbol resolution: -undefined dynamic_lookup Compiler optimizations: Changed from -O3 to -O2 Impact: This blocks any C++ extension development that links against libraries containing bfloat16 symbols on Xcode 17.0.0. The issue does not occur on Xcode 16.x. Linker Crash Dump Location: /var/folders/gn/7_g6wy1j66b8z3lkywyrbsx00000gn/T/linker-crash-* Expected Behavior: Linker should successfully link the extension, or at minimum, gracefully handle bfloat16 symbols without crashing. Temporary Solution: Downgrade to Xcode 16.x or use Python-only implementations until this is fixed in a future Xcode release.

I updated my project (a Swift-based Screen Saver) from Xcode 14 to 15, and while the project works fine, I'm seeing a bunch of warnings during the link phase like this: ld: warning: reexported library with install name '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis' found at '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis.tbd' couldn't be matched with any parent library and will be linked directly Am I doing something wrong? Can I safely suppress these warnings?