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. Again, this isn’t a separate tool. Rather, ld supported the -ld_classic and -ld_new options to select a specific implementation. Note During the Xcode 15 beta cycle these options were named -ld64 and -ld_prime. I continue to use those original names because the definition of new changes over time (some of us still think of ld64 as the new linker ;–). Note Xcode 27 beta removed the ld64 implementation. The ld tool now contains just the ld_prime implementation. 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. Version 3 introduced the concept of a launch closure, which is an important optimisation. 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 2026-07-06 Added the term launch closure. 2026-07-02 Added a note about fate of ld64. 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.

I am developing a large iOS application with an extensive UI test suite (hundreds of UI test scenarios). After upgrading our CI runners to macOS Tahoe 26, we started observing an intermittent issue where an iOS Simulator may operate normally for many successful application launches before unexpectedly entering a persistent degraded state. Once this occurs, every subsequent application launch crashes inside dyld before reaching our application’s main(). The degraded state persists until the simulator device is reset This causes UI tests to hang and eventually timeout. Business impact CI/CD jobs frequently timeout (90+ minutes per failed run) Significant loss of CI capacity Difficult to maintain reliable quality gates At our scale, this has become a serious issue affecting release confidence and overall engineering productivity. Technical details Crash report MyProject-2026-07-13-125307.ips — a crash report from a CI Demo project dyld_crash_demo — a minimal reproducible project demonstrating the relevant dyld execution path. The project intentionally returns errors from system functions along the shared cache initialization path to demonstrate that dyld continues execution until DyldSharedCache::getUUID(), where it subsequently crashes. Simply open the project and run it in iOS Simulator 26.2. Environment Component Version macOS Tahoe 26.x Xcode 26.2, 26.5 iOS Simulator 26.2, 26.5, 26.6 Architecture Apple Silicon dyld 1378 dyld_sim 1335 What we have ruled out multiple Xcode versions multiple macOS 26.x releases multiple iOS Simulator runtimes multiple simulator devices UI tests with parallel execution disabled deleting the simulator dyld shared cache recreating simulator devices application-specific issues (the crash happens before main()) The issue is still reproducible. Investigation The earliest observable failure sequence is consistently: shared_region_check_np() → "Cannot allocate memory" (ENOMEM) Shared cache mmap(0x180000000, ...) → EACCES The shared cache region remains unmapped DyldSharedCache::getUUID() reads 0x180000058 EXC_BAD_ACCESS (Translation fault) The crash occurs before any application code executes. The first faulting instruction belongs to DyldSharedCache::getUUID(), while the shared-cache region is still unmapped. Published dyld source analysis Relevant execution path: loadDyldCache() ↓ mapSplitCachePrivate() ↓ preflightCacheFile() Based on the published sources of dyld-1378, this appears to be the execution path leading to the observed failure. After the loadDyldCache() function failed to load the cache, dyld continued execution anyway and moved on to calling the DyldSharedCache::getUUID() function, where it subsequently failed. Additional observations Once the simulator enters the degraded state: simctl spawn succeeds. simctl launch crashes inside dyld before reaching main(). During our experiments, both processes were created by the same launchd_sim instance Before dyld::_dyld_start, both processes expose the same virtual address layout, including an unmapped shared-cache region (0x180000000–0x300000000). Current workaround As a temporary mitigation, we launch the application with DYLD_SHARED_REGION=avoid In our environment, this completely avoids the launch failures. However, this mode appears to be undocumented and intended primarily for debugging. We are concerned that it may change or stop working in future macOS or Xcode releases, so we are reluctant to depend on it in our production CI infrastructure. Questions 1. dyld Is it expected for dyld to continue dereferencing the shared-cache header after both the shared-region initialization and the shared-cache mapping have already failed? Execution appears to continue into: loadInfo.loadAddress->getUUID(cacheUuid) which results in an access to an unmapped address. The attached demo project reproduces this behavior by simulating failures from the shared-cache initialization path. Is there an expected fallback behavior for this situation or is continuing into DyldSharedCache::getUUID() the intended behavior ? 2. Simulator state Why does a simulator that initially launches applications successfully eventually enter a state where every subsequent launch fails while the shared cache can no longer be mapper? The earliest related system log we have found is: vm_shared_region_start_address() returned 0x1 Is this a known CoreSimulator or macOS Tahoe issue? If so, is there a supported workaround or recommended long-term solution besides DYLD_SHARED_REGION=avoid? Any guidance would be greatly appreciated.

The compiled size of my app (DerivedData/*/Build/Products/Debug-iphonesimulator/AppName.app) jumped 200 MB (926 MB-> 1.12 GB) just by compiling with Xcode 27 beta 2 (currently the latest). I can compile with Xcode 27, but when I run it on a simulator it crashes on launch. I get the same type of crash when running my unit tests. I'm getting a lot of warnings in the debug console about "Class X is implemented in both". I asked Claude to analyze the .app files to find the difference. Yes, I have a lot of internal and external packages/frameworks. Xcode26 ships 128 frameworks including 14 *_PackageProduct.framework dynamic frameworks (Logger_…, APICore_…, SplitManager_…, Apollo_…, PerModel_…, AppGateway_…, etc.). Xcode 27 ships 114 — all 14 of those dynamic package frameworks are gone. Xcode 27 changed the default and now links those SPM package products statically into every framework that consumes them. Counting framework binaries that carry their own copy of a package's Swift type metadata: ┌──────────────┬────────────┬─────────────┐ │ Package │ Xcode 26 │ Xcode 27 b2 │ ├──────────────┼────────────┼─────────────┤ │ Logger │ 12 │ 79 │ ├──────────────┼────────────┼─────────────┤ │ APICore │ 3 │ 45 │ ├──────────────┼────────────┼─────────────┤ │ SplitManager │ 1 │ 20 │ ├──────────────┼────────────┼─────────────┤ │ PerModel │ 1 │ 24 │ ├──────────────┼────────────┼─────────────┤ │ AppGateway │ 1 │ 20 │ └──────────────┴────────────┴─────────────┘ 79 copies of Logger's types instead of 1. That's the runtime problem: duplicate Swift type metadata / Objective-C class registration → "Class … is implemented in both …, one of the two will be used" and, when type identity or singletons matter, crashes. It hits unit tests hardest because the test bundle re-links the same static package that the host app's frameworks already contain. I worked on it a bit trying to switch my packages and frameworks to load dynamically. But that only gets so far as 3rd party packages like Apollo (for GraphQL) don't ship a dynamic version of ApolloTestSupport. I really don't like forking 3rd party packages. I tried changing my packages to explicitly load dynamically like this. That got me to the point that I could run on a simulator. But I was unable to get to the point that I could run all my unit tests without crashing on launch. And the code that runs on a simulator crashes on a device complaining about missing packages. products: [ .library( name: "AppGateway", + type: .dynamic, targets: ["AppGateway"]), ], Something is really different in Xcode 27 with the way it links packages and creates my app - a linker bug? I don't know if there is an ancient build setting that might be triggering this? Our app is really old. v1 was created in 2010. We just recently moved to a SceneUI delegate setup. I really don't know what would be a good next step for me to figure this one out. I am happy to use a DTS or create a Feedback if I thought it would help me get forward progress on this? Help?

Anyone else seeing a lot more "Class X is implemented in both ..." warnings on Xcode 27 than on Xcode 26? Same source, same flags, the count goes from a handful to a couple thousand, and some now correlate with real crashes (cast failures, missing protocol conformances) instead of the usual harmless first-wins behavior. Is this a known change in Swift 6.4 / Xcode 27? Is there a new flag I should be passing? Any suggestions welcome.

I am testing an existing iOS app with Xcode 27 beta 3. The build succeeds, but I am seeing a new linker warning from Swift Package product targets. ld: warning: address=0xF496F points before section(28) start and the target atom is ambiguous Environment: Xcode 27.0 beta 3 Build version: 27A5218g Platform: iOS Simulator Configuration: Debug Project type: iOS app with Swift Package dependencies, also embedding a watchOS app Build command: DEVELOPER_DIR=/Applications/Xcode-beta.app/Contents/Developer \ xcodebuild -project MyWeight/MyWeight.xcodeproj \ -scheme MyWeight \ -configuration Debug \ -destination "generic/platform=iOS Simulator" \ build The build succeeds: ** BUILD SUCCEEDED ** Warnings: MyWeight/MyWeightKit/Package.swift: MyWeightKit-watchOS-product: ld: warning: address=0xF493F points before section(28) start and the target atom is ambiguous MyWeight/MyWeightKit/Package.swift: MyWeightKit-iOS-product: ld: warning: address=0xF496F points before section(28) start and the target atom is ambiguous Both warnings appear during the link step for Swift Package product framework targets. Is this a known issue in Xcode 27 beta 3? Does it indicate a real issue in the produced simulator binary, or is it likely a linker/debug-info diagnostic?

I have a personal iOS project that I also compile for macOS with Catalyst. When built with Xcode 26.x, everything is linked correctly. When built with Xcode 27 betas, the following runtime error occurs: Termination Reason: Namespace DYLD, Code 4, Symbol missing Symbol not found: _UIFontTextStyleCallout Referenced from: <046ED276-F81A-31B4-82FF-6DC82E9041BC> /Applications/Photo Library.app/Contents/MacOS/Photo Library Expected in: <298B64F6-9BC0-3BFB-BE72-EBDC2BE0FF19> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit Any assistance? Thanks

We root-caused a launch crash that only affects ARCHIVED builds (Run/Debug works, simulator works) and filed it as FB23528109. Posting the details here because the crash signatures are hard to search for and other teams are likely to hit this as they adopt Swift 6.3 toolchains. SYMPTOM The archived app crashes before main() on device, on every launch. Depending on which orphaned pointer gets read first, the crash looks like one of these: EXC_BREAKPOINT, "pointer authentication trap DA", inside swift_conformsToProtocolMaybeInstantiateSuperclasses / _searchConformancesByMangledTypeName (often with a Firebase or other +load frame below it; that frame is just the first conformance scan at launch, not the cause) EXC_BAD_ACCESS KERN_INVALID_ADDRESS at a small, raw unslid address (e.g. 0xc118), inside dyld: resolveRebase <- objc_visitor::forEachClass <- dyld4::PrebuiltObjC::make Debug builds, simulator builds and Xcode Run builds are all fine, because the corruption happens in the Strip build phase, which only runs for Archive/install builds. ROOT CAUSE (two defects combine) strip -S -T (what Xcode runs on embedded frameworks during Archive when STRIP_SWIFT_SYMBOLS = YES) corrupts dyld chained fixups. When strip removes a Swift weak-definition symbol that has a GOT bind, it converts the bind into a rebase to the local definition (correct) but writes the converted entry with next = 0 (incorrect). That terminates the 16 KB page's fixup chain early, and every fixup after the converted slot in the same page is orphaned: dyld never processes it, so raw chain-encoding bytes get read as pointers at launch. The bug is present in every strip we tested: Xcode 26.3, 26.4, 26.4.1, 26.5, 26.6 and 27.0 beta 2. strip -S and strip -S -x (without -T) do not corrupt. Starting with Swift 6.3.0 (Xcode 26.4.0), the compiler emits the trigger pattern for ordinary code: cross-module references to a non-final class's stored-property accessors become weak-def-coalesce binds (Swift 6.2.4 emits none). So apps that embed a multi-module Swift dynamic framework (e.g. an SPM package built as one dynamic framework) started getting corrupted by their own default Archive pipeline when they moved past Xcode 26.3. HOW TO CHECK IF YOU ARE AFFECTED Compare the fixups of a framework binary inside your archive against a Run build of the same code: xcrun dyld_info -fixups YourApp.app/Frameworks/YourKit.framework/YourKit If fixups that exist in the Run build are missing after the archive's strip step (in particular __got slots and anything after them in the same 16 KB page), you are affected. Also: any GOT bind of a Swift ($s...) symbol in the pre-strip binary is a red flag. WORKAROUND Set STRIP_SWIFT_SYMBOLS = NO (optionally STRIP_STYLE = non-global, i.e. strip -S -x, which kept the size cost to about +4% for us). Important: if the affected framework is a Swift package product, these must be passed as xcodebuild command-line overrides (e.g. xcodebuild ... STRIP_SWIFT_SYMBOLS=NO STRIP_STYLE=non-global); xcconfig files do not apply to package targets. REPRO FB23528109 contains a complete minimal reproducer (4 small C files + 1 trivial Swift file, no proprietary code): a 30-second CLI script whose host binary segfaults through an orphaned pointer, and a default-settings Xcode project whose Run build works while its archived build crashes pre-main on device, identically for archives produced by Xcode 26.3.0, 26.4.0 and 26.6 (crash logs for each attached in the FB). Happy to share more details from the investigation if anyone is debugging the same signatures.

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 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?

Hi, we've getting error when we are building our app with Xcode 15 beta versions and Xcode 15.0 public release. ld: B/BL out of range 156662596 (max +/-128MB) to '' To fix this just add -ld64 to Other Linker Flags in Target.

After enabling Enhanced Security for an existing iOS project (mixed Objective-C / Swift) I get the linker error: Library 'c++polyfills' not found This happens when compiling for a simulator as run destination. Device builds (debug) or archiving a release build works. However I need to be able to test on a simulator... Xcode version is 26.4.1, Simulator uses iOS 26.4.1

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

I've recently installed Xcode 26.4, and it seems like all of our libraries now give multiple linker error when building of the format libtool: warning: 'Foo.o' has no symbols Most of these errors come from extensions over objc types written in objc. (for instance we have some extensions over NSArray in the file NSArray+NSSet.mm) Is that a new feature of some stricter libtool invocation? or a bug? should I do anything about it?

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