Apple’s library technology has a long and glorious history, dating all the way back to the origins of Unix. This does, however, mean that it can be a bit confusing to newcomers. This is my attempt to clarify some terminology. If you have any questions or comments about this, start a new thread and tag it with Linker so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" An Apple Library Primer Apple’s tools support two related concepts: Platform — This is the platform itself; macOS, iOS, iOS Simulator, and Mac Catalyst are all platforms. Architecture — This is a specific CPU architecture used by a platform. arm64 and x86_64 are both architectures. A given architecture might be used by multiple platforms. The most obvious example of this arm64, which is used by all of the platforms listed above. Code built for one platform will not work on another platform, even if both platforms use the same architecture. Code is usually packaged in either a Mach-O file or a static library. Mach-O is used for executables (MH_EXECUTE), dynamic libraries (MH_DYLIB), bundles (MH_BUNDLE), and object files (MH_OBJECT). These can have a variety of different extensions; the only constant is that .o is always used for a Mach-O containing an object file. Use otool and nm to examine a Mach-O file. Use vtool to quickly determine the platform for which it was built. Use size to get a summary of its size. Use dyld_info to get more details about a dynamic library. IMPORTANT All the tools mentioned here are documented in man pages. For information on how to access that documentation, see Reading UNIX Manual Pages. There’s also a Mach-O man page, with basic information about the file format. Many of these tools have old and new variants, using the -classic suffix or llvm- prefix, respectively. For example, there’s nm-classic and llvm-nm. If you run the original name for the tool, you’ll get either the old or new variant depending on the version of the currently selected tools. To explicitly request the old or new variants, use xcrun. The term Mach-O image refers to a Mach-O that can be loaded and executed without further processing. That includes executables, dynamic libraries, and bundles, but not object files. A dynamic library has the extension .dylib. You may also see this called a shared library. A framework is a bundle structure with the .framework extension that has both compile-time and run-time roles: At compile time, the framework combines the library’s headers and its stub library (stub libraries are explained below). At run time, the framework combines the library’s code, as a Mach-O dynamic library, and its associated resources. The exact structure of a framework varies by platform. For the details, see Placing Content in a Bundle. macOS supports both frameworks and standalone dynamic libraries. Other Apple platforms support frameworks but not standalone dynamic libraries. Historically these two roles were combined, that is, the framework included the headers, the dynamic library, and its resources. These days Apple ships different frameworks for each role. That is, the macOS SDK includes the compile-time framework and macOS itself includes the run-time one. Most third-party frameworks continue to combine these roles. A static library is an archive of one or more object files. It has the extension .a. Use ar, libtool, and ranlib to inspect and manipulate these archives. The static linker, or just the linker, runs at build time. It combines various inputs into a single output. Typically these inputs are object files, static libraries, dynamic libraries, and various configuration items. The output is most commonly a Mach-O image, although it’s also possible to output an object file. The linker may also output metadata, such as a link map (see Using a Link Map to Track Down a Symbol’s Origin). The linker has seen three major implementations: ld — This dates from the dawn of Mac OS X. ld64 — This was a rewrite started in the 2005 timeframe. Eventually it replaced ld completely. If you type ld, you get ld64. ld_prime — This was introduced with Xcode 15. This isn’t a separate tool. Rather, ld now supports the -ld_classic and -ld_new options to select a specific implementation. Note During the Xcode 15 beta cycle these options were -ld64 and -ld_prime. I continue to use those names because the definition of new changes over time (some of us still think of ld64 as the new linker ;–). The dynamic linker loads Mach-O images at runtime. Its path is /usr/lib/dyld, so it’s often referred to as dyld, dyld, or DYLD. Personally I pronounced that dee-lid, but some folks say di-lid and others say dee-why-el-dee. IMPORTANT Third-party executables must use the standard dynamic linker. Other Unix-y platforms support the notion of a statically linked executable, one that makes system calls directly. This is not supported on Apple platforms. Apple platforms provide binary compatibility via system dynamic libraries and frameworks, not at the system call level. Note Apple platforms have vestigial support for custom dynamic linkers (your executable tells the system which dynamic linker to use via the LC_LOAD_DYLINKER load command). This facility originated on macOS’s ancestor platform and has never been a supported option on any Apple platform. The dynamic linker has seen 4 major revisions. See WWDC 2017 Session 413 (referenced below) for a discussion of versions 1 through 3. Version 4 is basically a merging of versions 2 and 3. The dyld man page is chock-full of useful info, including a discussion of how it finds images at runtime. Every dynamic library has an install name, which is how the dynamic linker identifies the library. Historically that was the path where you installed the library. That’s still true for most system libraries, but nowadays a third-party library should use an rpath-relative install name. For more about this, see Dynamic Library Identification. Mach-O images are position independent, that is, they can be loaded at any location within the process’s address space. Historically, Mach-O supported the concept of position-dependent images, ones that could only be loaded at a specific address. While it may still be possible to create such an image, it’s no longer a good life choice. Mach-O images have a default load address, also known as the base address. For modern position-independent images this is 0 for library images and 4 GiB for executables (leaving the bottom 32 bits of the process’s address space unmapped). When the dynamic linker loads an image, it chooses an address for the image and then rebases the image to that address. If you take that address and subtract the image’s load address, you get a value known as the slide. Xcode 15 introduced the concept of a mergeable library. This a dynamic library with extra metadata that allows the linker to embed it into the output Mach-O image, much like a static library. Mergeable libraries have many benefits. For all the backstory, see WWDC 2023 Session 10268 Meet mergeable libraries. For instructions on how to set this up, see Configuring your project to use mergeable libraries. If you put a mergeable library into a framework structure you get a mergeable framework. Xcode 15 also introduced the concept of a static framework. This is a framework structure where the framework’s dynamic library is replaced by a static library. Note It’s not clear to me whether this offers any benefit over creating a mergeable framework. Earlier versions of Xcode did not have proper static framework support. That didn’t stop folks trying to use them, which caused all sorts of weird build problems. A universal binary is a file that contains multiple architectures for the same platform. Universal binaries always use the universal binary format. Use the file command to learn what architectures are within a universal binary. Use the lipo command to manipulate universal binaries. A universal binary’s architectures are either all in Mach-O format or all in the static library archive format. The latter is called a universal static library. A universal binary has the same extension as its non-universal equivalent. That means a .a file might be a static library or a universal static library. Most tools work on a single architecture within a universal binary. They default to the architecture of the current machine. To override this, pass the architecture in using a command-line option, typically -arch or --arch. An XCFramework is a single document package that includes libraries for any combination of platforms and architectures. It has the extension .xcframework. An XCFramework holds either a framework, a dynamic library, or a static library. All the elements must be the same type. Use xcodebuild to create an XCFramework. For specific instructions, see Xcode Help > Distribute binary frameworks > Create an XCFramework. Historically there was no need to code sign libraries in SDKs. If you shipped an SDK to another developer, they were responsible for re-signing all the code as part of their distribution process. Xcode 15 changes this. You should sign your SDK so that a developer using it can verify this dependency. For more details, see WWDC 2023 Session 10061 Verify app dependencies with digital signatures and Verifying the origin of your XCFrameworks. A stub library is a compact description of the contents of a dynamic library. It has the extension .tbd, which stands for text-based description (TBD). Apple’s SDKs include stub libraries to minimise their size; for the backstory, read this post. Use the tapi tool to create and manipulate stub libraries. In this context TAPI stands for a text-based API, an alternative name for TBD. Oh, and on the subject of tapi, I’d be remiss if I didn’t mention tapi-analyze! Stub libraries currently use YAML format, a fact that’s relevant when you try to interpret linker errors. If you’re curious about the format, read the tapi-tbdv4 man page. There’s also a JSON variant documented in the tapi-tbdv5 man page. Note Back in the day stub libraries used to be Mach-O files with all the code removed (MH_DYLIB_STUB). This format has long been deprecated in favour of TBD. Historically, the system maintained a dynamic linker shared cache, built at runtime from its working set of dynamic libraries. In macOS 11 and later this cache is included in the OS itself. Libraries in the cache are no longer present in their original locations on disk: % ls -lh /usr/lib/libSystem.B.dylib ls: /usr/lib/libSystem.B.dylib: No such file or directory Apple APIs, most notably dlopen, understand this and do the right thing if you supply the path of a library that moved into the cache. That’s true for some, but not all, command-line tools, for example: % dyld_info -exports /usr/lib/libSystem.B.dylib /usr/lib/libSystem.B.dylib [arm64e]: -exports: offset symbol … 0x5B827FE8 _mach_init_routine % nm /usr/lib/libSystem.B.dylib …/nm: error: /usr/lib/libSystem.B.dylib: No such file or directory When the linker creates a Mach-O image, it adds a bunch of helpful information to that image, including: The target platform The deployment target, that is, the minimum supported version of that platform Information about the tools used to build the image, most notably, the SDK version A build UUID For more information about the build UUID, see TN3178 Checking for and resolving build UUID problems. To dump the other information, run vtool. In some cases the OS uses the SDK version of the main executable to determine whether to enable new behaviour or retain old behaviour for compatibility purposes. You might see this referred to as compiled against SDK X. I typically refer to this as a linked-on-or-later check. Apple tools support the concept of autolinking. When your code uses a symbol from a module, the compiler inserts a reference (using the LC_LINKER_OPTION load command) to that module into the resulting object file (.o). When you link with that object file, the linker adds the referenced module to the list of modules that it searches when resolving symbols. Autolinking is obviously helpful but it can also cause problems, especially with cross-platform code. For information on how to enable and disable it, see the Build settings reference. Mach-O uses a two-level namespace. When a Mach-O image imports a symbol, it references the symbol name and the library where it expects to find that symbol. This improves both performance and reliability but it precludes certain techniques that might work on other platforms. For example, you can’t define a function called printf and expect it to ‘see’ calls from other dynamic libraries because those libraries import the version of printf from libSystem. To help folks who rely on techniques like this, macOS supports a flat namespace compatibility mode. This has numerous sharp edges — for an example, see the posts on this thread — and it’s best to avoid it where you can. If you’re enabling the flat namespace as part of a developer tool, search the ’net for dyld interpose to learn about an alternative technique. WARNING Dynamic linker interposing is not documented as API. While it’s a useful technique for developer tools, do not use it in products you ship to end users. Apple platforms use DWARF. When you compile a file, the compiler puts the debug info into the resulting object file. When you link a set of object files into a executable, dynamic library, or bundle for distribution, the linker does not include this debug info. Rather, debug info is stored in a separate debug symbols document package. This has the extension .dSYM and is created using dsymutil. Use symbols to learn about the symbols in a file. Use dwarfdump to get detailed information about DWARF debug info. Use atos to map an address to its corresponding symbol name. Different languages use different name mangling schemes: C, and all later languages, add a leading underscore (_) to distinguish their symbols from assembly language symbols. C++ uses a complex name mangling scheme. Use the c++filt tool to undo this mangling. Likewise, for Swift. Use swift demangle to undo this mangling. For a bunch more info about symbols in Mach-O, see Understanding Mach-O Symbols. This includes a discussion of weak references and weak definition. If your code is referencing a symbol unexpectedly, see Determining Why a Symbol is Referenced. To remove symbols from a Mach-O file, run strip. To hide symbols, run nmedit. It’s common for linkers to divide an object file into sections. You might find data in the data section and code in the text section (text is an old Unix term for code). Mach-O uses segments and sections. For example, there is a text segment (__TEXT) and within that various sections for code (__TEXT > __text), constant C strings (__TEXT > __cstring), and so on. Over the years there have been some really good talks about linking and libraries at WWDC, including: WWDC 2023 Session 10268 Meet mergeable libraries WWDC 2022 Session 110362 Link fast: Improve build and launch times WWDC 2022 Session 110370 Debug Swift debugging with LLDB WWDC 2021 Session 10211 Symbolication: Beyond the basics WWDC 2019 Session 416 Binary Frameworks in Swift — Despite the name, this covers XCFrameworks in depth. WWDC 2018 Session 415 Behind the Scenes of the Xcode Build Process WWDC 2017 Session 413 App Startup Time: Past, Present, and Future WWDC 2016 Session 406 Optimizing App Startup Time Note The older talks are no longer available from Apple, but you may be able to find transcripts out there on the ’net. Historically Apple published a document, Mac OS X ABI Mach-O File Format Reference, or some variant thereof, that acted as the definitive reference to the Mach-O file format. This document is no longer available from Apple. If you’re doing serious work with Mach-O, I recommend that you find an old copy. It’s definitely out of date, but there’s no better place to get a high-level introduction to the concepts. The Mach-O Wikipedia page has a link to an archived version of the document. For the most up-to-date information about Mach-O, see the declarations and doc comments in <mach-o/loader.h>. Revision History 2025-08-04 Added a link to Determining Why a Symbol is Referenced. 2025-06-29 Added information about autolinking. 2025-05-21 Added a note about the legacy Mach-O stub library format (MH_DYLIB_STUB). 2025-04-30 Added a specific reference to the man pages for the TBD format. 2025-03-01 Added a link to Understanding Mach-O Symbols. Added a link to TN3178 Checking for and resolving build UUID problems. Added a summary of the information available via vtool. Discussed linked-on-or-later checks. Explained how Mach-O uses segments and sections. Explained the old (-classic) and new (llvm-) tool variants. Referenced the Mach-O man page. Added basic info about the strip and nmedit tools. 2025-02-17 Expanded the discussion of dynamic library identification. 2024-10-07 Added some basic information about the dynamic linker shared cache. 2024-07-26 Clarified the description of the expected load address for Mach-O images. 2024-07-23 Added a discussion of position-independent images and the image slide. 2024-05-08 Added links to the demangling tools. 2024-04-30 Clarified the requirement to use the standard dynamic linker. 2024-03-02 Updated the discussion of static frameworks to account for Xcode 15 changes. Removed the link to WWDC 2018 Session 415 because it no longer works )-: 2024-03-01 Added the WWDC 2023 session to the list of sessions to make it easier to find. Added a reference to Using a Link Map to Track Down a Symbol’s Origin. Made other minor editorial changes. 2023-09-20 Added a link to Dynamic Library Identification. Updated the names for the static linker implementations (-ld_prime is no more!). Removed the beta epithet from Xcode 15. 2023-06-13 Defined the term Mach-O image. Added sections for both the static and dynamic linkers. Described the two big new features in Xcode 15: mergeable libraries and dependency verification. 2023-06-01 Add a reference to tapi-analyze. 2023-05-29 Added a discussion of the two-level namespace. 2023-04-27 Added a mention of the size tool. 2023-01-23 Explained the compile-time and run-time roles of a framework. Made other minor editorial changes. 2022-11-17 Added an explanation of TAPI. 2022-10-12 Added links to Mach-O documentation. 2022-09-29 Added info about .dSYM files. Added a few more links to WWDC sessions. 2022-09-21 First posted.

Using xcode 26 with linker flag -ld_classic，get an error ： 0 0x1042b9778 __assert_rtn + 160 1 0x1042bc560 ld::tool::SymbolTableAtom&lt;x86_64&gt;::classicOrdinalForProxy(ld::Atom const*) (.cold.3) + 0 2 0x1041f3da8 ld::tool::SymbolTableAtom&lt;x86_64&gt;::classicOrdinalForProxy(ld::Atom const*) + 172 3 0x1041f4c1c ld::tool::SymbolTableAtom::addImport(ld::Atom const*, ld::tool::StringPoolAtom*) + 140 4 0x1041f6500 ld::tool::SymbolTableAtom::encode() + 396 5 0x1041e83a8 ___ZN2ld4tool10OutputFile20buildLINKEDITContentERNS_8InternalE_block_invoke.413 + 36 6 0x182a95b2c _dispatch_call_block_and_release + 32 7 0x182aaf85c _dispatch_client_callout + 16 8 0x182acc478 _dispatch_channel_invoke.cold.5 + 92 9 0x182aa7fa4 _dispatch_root_queue_drain + 736 10 0x182aa85d4 _dispatch_worker_thread2 + 156 11 0x182c49e28 _pthread_wqthread + 232 A linker snapshot was created at: /tmp/app-2025-06-13-215652.ld-snapshot ld: Assertion failed: (it != _dylibToOrdinal.end()), function dylibToOrdinal, file OutputFile.cpp, line 5196. clang++: error: linker command failed with exit code 1 (use -v to see invocation)

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?

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)

When building our project for Mac Catalyst with Xcode 26.2, we get this warning almost a hundred times, once for every object file: directory not found for option '-L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' Somehow, every Link <FileName>.o build step got the following parameter, regardless if the target contained Metal files or not: -L/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst The toolchain is mounted at this point, but the directory usr/lib/swift/maccatalyst doesn't exist. When building the project for iOS, the option doesn't exist and the warning is not shown. We already check the build settings, but we couldn't find a reason why the linker is trying to link against the toolchain here. Even for targets that do contain Metal files, we get the following linker warning: search path '/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.3.48.0.UZtKea/Metal.xctoolchain/usr/lib/swift/maccatalyst' not found Is this a known issue? Is there a way to get rid of these warnings?

I created 2 iOS projects in Xcode: Project 1: 4 targets (main app + 3 app extensions) 4 static libraries the main app's target dependencies include - 3 app extensions and the 4 libs. the main app's binary is linked to all 4 libs similarly, each extension is linked to all 4 libs Project 2: 5 targets (main app + 3 app extensions + 1 framework) 4 static libraries the main app's target dependencies include - 3 app extensions and the framework each extension is dependent only on the framework the framework's target dependencies include all the 4 static libs As per my understanding, the app bundle size for Project 2 should be less than that of Project 1, since we eliminate duplicating the static libs for each target by using a framework instead. However, I have found that the bundle size is more for Project 2 as compared to the bundle size of project 1. I do not understand, why?

Hello.

On my app I have the necessity to use mergeable libraries, in my context my libraries are indirect dependency, in other words the dependency isn’t target in my project, and they are XCFramework where they are imported on Framework, Libraries, and Embedded Content session on my app target. Following the documentation on Configuring your project to use mergeable libraries it said. 
  But on Manually configure merging don’t said how to configure to indirect dependencies. 
  So I have tried configure use the linker flag -merge_framework for each XCFramework using -Wl, -merge_framework, {XCFramework_Name}, but I am receiving the following error unknown argument: -merge_framework’ when build the release. 

In app target is set build settings MERGED_BINARY_TYPE = manual; The question is: 
 Is possible using mergeable libraries in XCFramework dependencies ? How I do this? Because on the doc is not clear how to use in indirect dependency like XCFramework. 

 Regards 
Michel Carvalho

I am working on a cross-platform application where, on Android and Windows, I explicitly load dynamic libraries at runtime (e.g., LoadLibrary/GetProcAddress on Windows and equivalent mechanisms on Android). This allows me to control when and how modules are loaded, and to transfer execution flow from the main executable into the dynamically loaded library. I want to follow a similar approach on macOS (and also iOS) and explicitly load a framework (instead of relying on implicit linking via import). From my exploration so far, I have come across the following options: Using Bundle (NSBundle) - Load framework using: let bundle = Bundle(path: path) try bundle?.load() Access functionality via NSPrincipalClass and @objc methods (class-based entry) Using dlopen + dlsym Load the framework binary and resolve symbols: let handle = dlopen(path, RTLD_NOW) let sym = dlsym(handle, "EntryPoint") Expose Swift functions using @_cdecl Using a hybrid approach (Bundle + dlsym) - Use Bundle for loading and dlsym for symbol access From what I understand: Bundle works well for class-based/plugin-style designs using the Objective-C runtime while dlopen/dlsym works at the symbol level and is closer to what I am doing on other platforms However, my requirement is specifically: Explicit runtime loading (not compile-time linking) Ability to transfer execution flow from the main executable into the dynamically loaded framework **What is the recommended approach on macOS for this kind of explicit dynamic loading, or is implicit loading the way to go? Also, would it differ for interactive and non-interactive apps? ** In what scenarios would Apple recommend using Bundle instead of dlopen? Is there any other methods best for this explicit loading of frameworks on Apple?

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

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?

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?

Xcode 16.2 Flutter version 3.27.1 0 0x1008abee4 __assert_rtn + 160 1 0x1008add9c ld::tool::OutputFile::setFixup64(unsigned char*, unsigned long long, ld::Atom const*) (.cold.3) + 0 2 0x100789640 ld::tool::OutputFile::setFixup64(unsigned char*, unsigned long long, ld::Atom const*) + 656 3 0x100785b78 ld::tool::OutputFile::applyFixUps(ld::Internal&amp;, unsigned long long, ld::Atom const*, unsigned char*) + 4388 4 0x10078be18 ___ZN2ld4tool10OutputFile10writeAtomsERNS_8InternalEPh_block_invoke + 488 5 0x19bc19428 _dispatch_client_callout2 + 20 6 0x19bc2d850 _dispatch_apply_invoke3 + 336 7 0x19bc193e8 _dispatch_client_callout + 20 8 0x19bc1ac68 _dispatch_once_callout + 32 9 0x19bc2c8a4 _dispatch_apply_invoke + 252 10 0x19bc193e8 _dispatch_client_callout + 20 11 0x19bc2b080 _dispatch_root_queue_drain + 864 12 0x19bc2b6b8 _dispatch_worker_thread2 + 156 13 0x19bdc5fd0 _pthread_wqthread + 228 A linker snapshot was created at: /tmp/Test Kopi Kenangan.debug.dylib-2025-02-27-100512.ld-snapshot ld: Assertion failed: (reconstituted == accumulator), function setFixup64, file OutputFile.cpp, line 2975. clang: error: linker command failed with exit code 1 (use -v to see invocation)

My app cannot be launched on some users' MacOS, it says "Library not loaded: /usr/lib/libc++.1.dylib". "exception" : {"codes":"0x0000000000000000, 0x0000000000000000","rawCodes":[0,0],"type":"EXC_CRASH","signal":"SIGABRT"}, "termination" : {"code":1,"flags":518,"namespace":"DYLD","indicator":"Library missing","details":["(terminated at launch; ignore backtrace)"],"reasons":["Library not loaded: \/usr\/lib\/libc++.1.dylib","Referenced from: &lt;E4CB6764-8CB9-32E9-881B-252E2F3E0C4B&gt; \/Applications\/myapp.app\/Contents\/MacOS\/myapp","Reason: tried: '\/System\/iOSSupport\/usr\/lib\/libc++.1.dylib' (no such file), '\/System\/Volumes\/Preboot\/Cryptexes\/OS\/System\/iOSSupport\/usr\/lib\/libc++.1.dylib' (no such file), '\/System\/iOSSupport\/usr\/lib\/libc++.1.dylib' (no such file, no dyld cache), '\/usr\/lib\/libc++.1.dylib' (no such file), '\/System\/Volumes\/Preboot\/Cryptexes\/OS\/usr\/lib\/libc++.1.dylib' (no such file), '\/usr\/lib\/libc++.1.dylib' (no such file, no dyld cache)"]}, User 1's environment: 2020 MacBook Air, M1, system version 15.4. User 2's environment: 2020 MacBook Pro, M1, system version: 15.5. I (and the people around me) cannot reproduce this problem. It can be reproduced on User 2's computer, but the performance is strange, sometimes good and sometimes bad. The app can be launched normally during the day, and it can also be launched normally after restarting the computer. But it cannot be launched from 21:00 to 22:00 at night, and the problem still exists even if the computer is restarted. After some searching, I suspect that there is a bug in the dynamic linker cache mechanism of MacOS, but we cannot confirm it. According to the official documentation: https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-release-notes New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. Code that attempts to check for dynamic library presence by looking for a file at a path or enumerating a directory will fail. Instead, check for library presence by attempting to dlopen() the path, which will correctly check for the library in the cache. (62986286) I also tried to manually copy libc++.1.dylib to the above path, but these paths are read-only, and files cannot be copied into them even if SIP is turned off. Is there any other way to fix or avoid this problem? Thank you. Other similar questions: https://developer.apple.com/forums/thread/756370 https://developer.apple.com/forums/thread/764824

Hi ! I'm currently stuck with an issue on Xcode, I'll try explain to the best I can :-) I have a workspace (that I need to keep that way, I can't split projects) that contains multiple projects. I have 2 frameworks : Core and Draw. Draw depends on Core. So far so good. I needed to create a test application that can be modular and link my framewok, but also other drawing frameworks. To that extend, I created a CardLIbrary framewok, and a CardAdapter framewok, and I linked them into the test application. Test App └── DrawCardAdapter │ └── CardAdapter │ └── CardLibrary │ └── Core │ └── TCA (SPM) │ └── Draw │ └── Core Here, all dependencies are local ones if not stated otherwise (for the SPM). CardLibrary is a framework that generates only UI (linked to Core for logging purposes, nothing fancy). I also added TCA which is a SPM dependency, it may generate some issues after. CardAdapter is an abstraction for CardLibrary. Basically, it acts as an interface between CardLibrary and Test Application. DrawCardAdapter is the actual implementation of CardAdapter using local Draw framework. Why so complex ? Because I need to be able to do this: Test App └── ExternalDrawCardAdapter │ └── CardAdapter │ └── CardLibrary │ └── Core │ └── TCA (SPM) │ └── ExternalDrawFramework With this architecture, I can create a new ExternalDrawCardAdapter that implents the CardAdapter logic. This new framework does not relies on my Draw framework, and yet, I can still generate a test application that visually looks and feel like all others, but use a completely different drawing engine underneath. To do that, the Test App code only uses inputs and outputs from CardAdapter (the protocol), not concrete implementations like DrawCardAdapter or ExternalDrawCardAdapter. But to be able to make it work, I have 2 test ap targets : a DrawTestApp and a ExternalDrawTestApp. All code files are shared, except a SdkLauncher that is target specific and acutally loads the proper implementation. So the SdkLauncher for DrawTestApp is linked to the DrawCardAdapter (embed and sign) and loads DrawCardAdapter framework, whereas the ExternalDrawTestApp is linked to the ExternalDrawCardAdapter (embed and sign) and loads ExternalDrawCardAdapter framework. Now it looks like this (I only show local stuff othewise it would be too complicated :D) So far so good, this works well. Now, for the part that fails. My Draw and Core frameworks are frameworks that I release for my customers (Cocoapod), and I wanted to be able to test my productions frameworks with the test app (it's that actual purpose of the test app : being able to test development and released SDKs) To do so, I duplicated every target and removed local dependency for a cocoapod dependency. All targets were named -pod, but the actual module and product name are still the same (I tried differently, it did not work either, I'll explain it later). Test App └── DrawCardAdapter │ └── CardAdapter │ └── CardLibrary │ └── Core │ └── TCA (SPM) │ └── Draw │ └── Core │ Test App Pod └── DrawCardAdapter-pod │ └── CardAdapter-pod │ └── CardLibrary-pod │ └── Core-pod │ └── TCA (SPM) │ └── Draw-pod │ └── Core-pod Once again, it's only targets, every project would look like CardAdapter └── CardAdapter └── CardAdapter-pod It continues to use local targets, except for the DrawCardAdapter-pod that actually loads Draw and Core from a Podfile instead of using the lkocal frameworks. But now for the part that fails : even though TestApp-pod does not link any local frameworks, I get a warning Multiple targets match implicit dependency for product reference 'Draw.framework'. Consider adding an explicit dependency on the intended target to resolve this ambiguity. And actually, Xcode ends up packaging the wrong framework. I can check it but showing in the app the Draw framework version, and it's always the local one, not the one specified in the podfile. For the record, I get this message for all 3 frameworks of course. I tried sooooo many things, that did not work of course: renaming the -pod frameworks so that the names are different (I had to rename all imports too). It works for all local frameworks (Lilbrary and Adapter basically), but not for Draw and Core (since I don't have -podversions of thoses framewoks of course). Creating a new local workspace that only handles -pod versions. Does not work since as we work as a team, I have to keep the shared schemes, and all workspaces see all targets and schemes. I also tried with a separate derived data folder, but I end up with some compilation issues. It seems that mixing local, cocoapod and spm dependencies inside the same workspace is not well handled) using explicit Target Dependenciesfrom the build phase. I end up with some compilation issues creating local podspecs for Library and Adapter. It fails because TCA is linked with SPM and apparently not copied when using podspecs. To the few ones that stayed so far, thanks for your patience :D I hope that @eskimo will drop by as you always were my savior in the end :D :D

My Xcode project fails to run with the following crash log any time I use a new SwiftUI symbol such as ConcentricRectangle or .glassEffect. I've tried using the legacy linker to no avail. It compiles perfectly fine, and I've tried targeting just macOS 26 also to no avail. This is a macOS project that's compiled just fine for years and compiles and runs on macOS going back to 13.0. Failed to look up symbolic reference at 0x118e743cd - offset 1916987 - symbol symbolic _____y_____y_____y_____yAAyAAy_____y__________G_____G_____yAFGGSg_ACyAAy_____y_____SSG_____y_____SgGG______tGSgACyAAyAAy_____ATG_____G_AVtGSgtGGAQySbGG______Qo_ 7SwiftUI4ViewPAAE11glassEffect_2inQrAA5GlassV_qd__tAA5ShapeRd__lFQO AA15ModifiedContentV AA6VStackV AA05TupleC0V AA01_hC0V AA9RectangleV AA5ColorV AA12_FrameLayoutV AA24_BackgroundStyleModifierV AA6IDViewV 8[ ]012EditorTabBarC0V AA022_EnvironmentKeyWritingS0V A_0W0C AA7DividerV A_0w4JumpyC0V AA08_PaddingP0V AA07DefaultgeH0V in /Users/[ ]/Library/Developer/Xcode/DerivedData/[ ]-grfjhgtlsyiobueapymobkzvfytq/Build/Products/Debug/[ ]/Contents/MacOS/[ ].debug.dylib - pointer at 0x119048408 is likely a reference to a missing weak symbol Example crashing code: import SwiftUI struct MyView: View { var body: some View { if #available(macOS 26.0, *) { Text("what the heck man").glassEffect() } } }

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.

I've got a large and complex app which has several dependencies upon 3rd party libraries (installed as pods). The app is structured according to Model-View-Controller design and there is a requirement to implement the Model part as an .xcframework so it can be included and used in the original app along with a few new apps. However, Apple documentation states that umbrella frameworks are not supported (Technical Note TN2435). The Model code has several dependencies which would be totally unfeasible to replace or remove, for example it uses RealmSwift for database storage. Obviously it would be impossible to write one's own database storage scheme in place of using Realm. However, if my framework uses Realm as a dependency, then its now become an umbrella framework. So therefore not supported according to Apple documentation. So what are options/solutions?

I build app success full, but app is crash when it's install and start on simulator, please help to resolve the issue. xcode version 16.3 dyld`__abort_with_payload: Thread 1: signal SIGABRT Console error log: dyld[27267]: Symbol not found: _$sSo18WKPDFConfigurationC6WebKitE4rectSo6CGRectVSgvs Referenced from: &lt;9ED011A5-B4BE-3B0B-98C6-0AFAF76A5B6C&gt; ..../Library/Developer/CoreSimulator/Devices/C94520D8-031D-4D91-8050-859E0951D1A6/data/Containers/Bundle/Application/522BF7A2-7633-4FF1-BA02-130727B8E65C/App.app/Frameworks/flutter_inappwebview_ios.framework/flutter_inappwebview_ios Expected in: &lt;0085D0EC-09E4-3699-ACE9-9B0C20B090BB&gt; /Library/Developer/CoreSimulator/Volumes/iOS_22C150/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.2.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/WebKit.framework/WebKit Symbol not found: _$sSo18WKPDFConfigurationC6WebKitE4rectSo6CGRectVSgvs Referenced from: &lt;9ED011A5-B4BE-3B0B-98C6-0AFAF76A5B6C&gt; ..../Library/Developer/CoreSimulator/Devices/C94520D8-031D-4D91-8050-859E0951D1A6/data/Containers/Bundle/Application/522BF7A2-7633-4FF1-BA02-130727B8E65C/App.app/Frameworks/flutter_inappwebview_ios.framework/flutter_inappwebview_ios Expected in: &lt;0085D0EC-09E4-3699-ACE9-9B0C20B090BB&gt; /Library/Developer/CoreSimulator/Volumes/iOS_22C150/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.2.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/WebKit.framework/WebKit dyld config: DYLD_SHARED_CACHE_DIR=.../Library/Developer/CoreSimulator/Caches/dyld/24D81/com.apple.CoreSimulator.SimRuntime.iOS-18-2.22C150 DYLD_ROOT_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22C150/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.2.simruntime/Contents/Resources/RuntimeRoot DYLD_LIBRARY_PATH=...../Library/Developer/Xcode/DerivedData/App-fdpvmjxapalesmhcoroqmpqwlxxm/Build/Products/Debug-iphonesimulator:/Library/Developer/CoreSimulator/Volumes/iOS_22C150/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.2.simruntime/Contents/Resources/RuntimeRoot/usr/lib/system/introspection DYLD_INSERT_LIBRARIES=/Library/Developer/CoreSimulator/Volumes/iOS_22C150/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.2.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libLogRedirect.dylib:/Library/Developer/CoreSimulator/Volumes/iOS_22C150/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.2.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libBacktraceRecording.dylib:/Library/Developer/CoreSimulator/Volumes/iOS_22C150/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.2.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libMainThreadChecker.dylib:/usr/lib/libRPAC.dylib:/Library/Developer/CoreSimulator/Volumes/iOS_22C150/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.2.simruntime/Contents/Resources/RuntimeRoot/usr/lib/libViewDebuggerSupport.dylib DYLD_FRAMEWORK_PATH=.....Library/Developer/Xcode/DerivedData/App-fdpvmjxapalesmhcoroqmpqwlxxm/Build/Products/Debug-iphonesimulator DYLD_FALLBACK_FRAMEWORK_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22C150/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.2.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks DYLD_FALLBACK_LIBRARY_PATH=/Library/Developer/CoreSimulator/Volumes/iOS_22C150/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.2.simruntime/Contents/Resources/RuntimeRoot/usr/lib

The project at hand is quite complex, and the link content is especially. I suddenly saw this warning again in recent days and wanted to inquire about when this deletion would be done, so that our team could make preparations and plan in advance.

I'm trying to run a simple C++ script, but for some reason I keep getting an error. Where /usr/lib/libc++.1.dylib cannot be found. Specifically, dyld[2012]: dyld cache '(null)' not loaded: syscall to map cache into shared region failed dyld[2012]: Library not loaded: /usr/lib/libc++.1.dylib Reason: tried: '/usr/lib/libc++.1.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libc++.1.dylib' (no such file), '/usr/lib/libc++.1.dylib' (no such file, no dyld cache) I tried reinstalling Xcode with no success. Can I get some help?