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, dynamic libraries, bundles, and object files. 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. 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. One of the most common points of confusion with dynamic linker is the way that the dynamic linker identifies dynamic libraries. There are two standard approaches to this, as described in 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. Stub libraries currently use YAML format, a fact that’s relevant when you try to interpret linker errors. Use the tapi tool to create and manipulate these files. 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! 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 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. 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 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 often find myself helping folks with dynamic library problems. These problems manifest in many different ways, but they all have one common factor: The dynamic library has an atypical install name. Sometimes this was inherited from macOS’s deep past, but most often it’s because folks aren’t aware of the two well-trodden paths through this particular minefield. This post is my attempt to rectify that. If you have questions or comments about this, start a new thread here on DevForums. 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" Dynamic Library Identification Apple’s dynamic linker has a lot of flexibility. Much of this flexibility exists for historical reasons, and it’s better for modern programs to follow one of two well-trodden paths: Most dynamic libraries should use an rpath-relative install name, as explained in Dynamic Library Standard Setup for Apps. In some cases it might make sense to use a full path for your install name, per Dynamic Library Full Path Alternative. To understand these options, you need to know a little bit about how the dynamic linker works, which is the subject of this post. Note This post covers some of the same ground as Embedding nonstandard code structures in a bundle, but in a less official way (-: Install Name Every dynamic library has an install name. This name identifies the library to the dynamic linker. When you link to a dynamic library, the static linker records the library’s install name in your Mach-O image. When the dynamic linker loads your Mach-O image, it uses those recorded install names to find and load the libraries you depend on. Note There are many different aliases for the term install name, including id, identification name, or install path. To see a library’s install name, run otool and examine the LC_ID_DYLIB load command: % otool -l libWaffle.dylib | grep -A 2 LC_ID_DYLIB cmd LC_ID_DYLIB cmdsize 48 name @rpath/libWaffle.dylib … Note The Mach-O load commands and their associated structures are defined in <mach-o/loader.h>. For example LC_ID_DYLIB is associated with the dylib_command structure. To see the install names of the libraries imported by a Mach-O image, run otool and examine the LC_LOAD_DYLIB load commands: % otool -l libVarnish.dylib | grep -A 2 LC_LOAD_DYLIB cmd LC_LOAD_DYLIB cmdsize 48 name @rpath/libWaffle.dylib … -- cmd LC_LOAD_DYLIB cmdsize 56 name /usr/lib/libSystem.B.dylib … Alternatively, use the -L option: % otool -L libVarnish.dylib … @rpath/libVarnish.dylib … @rpath/libWaffle.dylib … /usr/lib/libSystem.B.dylib … This displays the library’s own install name first, followed by the install names of all the libraries it imports. If you’re building a dynamic library with Xcode, use the Dynamic Library Install Name build setting to set the install name. If you’re building from the command line, pass the -install_name option to ld. For more about this, see the ld man page. It’s best to set the install name at build time and not change it. However, if you’re working with an existing dynamic library that has the wrong install name, you can usually change it using install_name_tool. See the install_name_tool man page for details. Runtime Path List Way back in the day, a dynamic library’s install name was the full path of the installed library. That’s why it’s called the install name. However, full paths don’t work in some situations. For example, if you have a library embedded within an app, you can’t use an full path because the app might not be installed in the Applications folder. To address this problem Apple updated the dynamic linker to support a number of special install name prefixes. At runtime it replaces the prefix with an appropriate path. For example, @executable_path is replaced with the path to the directory containing the processes main executable. For a full list of these prefixes see the dyld man page. However, if you’re creating a dynamic library you’ll want to focus on the runtime path, @rpath, or just rpath for short. The exact details of how this works are complex, see the man page for the full story, but the basic gist is that: The dynamic linker maintains a list of rpath directories. When it loads a Mach-O image, the dynamic linker looks for LC_RPATH load commands in the image. For each one it finds, it adds a new directory to the rpath list. When a Mach-O image imports a library with an rpath-relative install name, the dynamic linker searches for that library in each directory in the list. This may sound a bit abstract, so you might want to hop on over to Dynamic Library Standard Setup for Apps for some examples of how this works in practice. If you’re building a Mach-O image with Xcode, use the Runpath Search Paths build setting to add rpath directories. If you’re building from the command line, pass the -rpath option to ld. For more about this, see the ld man page. It’s best to configure your rpath directories at build time. However, if you’re working with an existing Mach-O that has the wrong rpath directories, you can add, delete, and change them using install_name_tool. See the install_name_tool man page for details.

We are seeing a crash on Big Sur 11.7.10 after switching the build system to use Xcode 15 Excerpt from crash Time Awake Since Boot: 1700 seconds System Integrity Protection: enabled Crashed Thread: 0 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: DYLD, [0x4] Symbol missing Application Specific Information: dyld: launch, loading dependent libraries Dyld Error Message: Symbol not found: __ZNSt3__17codecvtIDiDu11__mbstate_tE2idE Referenced from: /Applications/SecureworksTaegis.app/Contents/MacOS/com.secureworks.agent.daemon.app/Contents/MacOS/com.secureworks.agent.daemon Expected in: /usr/lib/libc++.1.dylib in /Applications/SecureworksTaegis.app/Contents/MacOS/com.secureworks.agent.daemon.app/Contents/MacOS/com.secureworks.agent.daemon Build system has the following specs : ProductName: macOS ProductVersion: 14.3.1 BuildVersion: 23D60 Xcode 15.2 Build version 15C500b CMAKE PROPS set(CMAKE_CXX_STANDARD 20) set(CMAKE_CXX_EXTENSIONS OFF) set(CMAKE_OSX_DEPLOYMENT_TARGET 11.0)

Hey, when I try to run my project on an iOS Simulator, I get the following message: JournalingSuggestions is not available when building for iOS Simulator. and Linker command failed with exit code 1 (use -v to see invocation) Steps to reproduce this behavior: Create a new Xcode project Add the Journaling Suggestions Capability Add the Journaling Suggestions Framework Under "Target > Build Phases > Link Binary with Libraries", select “optional“ for JournalingSuggestions.framework Under "Target > Build Settings > Other Linker Flags > Debug" select „Plus“ and add „iOS or iOS Simulator“ and paste this -Xlinker -weak_framework -Xlinker JournalingSuggestions into the editable field. Do the same for "Target > Build Settings > Other Linker Flags > Release" This tread is about the same problem, but is already checked as answered. That's why I'm creating this new tread. The last two bullet points are results from advice from the other thread. MacBook Air, M1, 2020, macOS: 14.6.1, Xcode: 16.0 Thanks for your help!

When I import starts models in Jupyter notebook, I ge the following error: ImportError: dlopen(/opt/anaconda3/lib/python3.12/site-packages/scipy/linalg/_fblas.cpython-312-darwin.so, 0x0002): Library not loaded: @rpath/liblapack.3.dylib Referenced from: &lt;5ACBAA79-2387-3BEF-9F8E-6B7584B0F5AD&gt; /opt/anaconda3/lib/python3.12/site-packages/scipy/linalg/_fblas.cpython-312-darwin.so Reason: tried: '/opt/anaconda3/lib/python3.12/site-packages/scipy/linalg/../../../../liblapack.3.dylib' (no such file), '/opt/anaconda3/lib/python3.12/site-packages/scipy/linalg/../../../../liblapack.3.dylib' (no such file), '/opt/anaconda3/bin/../lib/liblapack.3.dylib' (no such file), '/opt/anaconda3/bin/../lib/liblapack.3.dylib' (no such file), '/usr/local/lib/liblapack.3.dylib' (no such file), '/usr/lib/liblapack.3.dylib' (no such file, not in dyld cache). What should I do?

I’m a bit confused about the practicality and support for Umbrella frameworks in iOS. I’ve read that they’re not supported, but I’ve come across a few tutorials where people are developing Umbrella frameworks. Can anyone provide some insight on this?

I very recently migrated our project on Swift 6. After fixing every issues, mostly due to Swift Concurrency, I’m getting the following error when compiling with Xcode 16.0, which doesn’t make any sense to me : Multiple errors: file cannot be open()ed, errno=2 path=/Users/.../Library/Developer/Xcode/DerivedData/MyApp-euxwyncffackymerzuntbjccezyq/Build/Intermediates.noindex/MyApp.build/Debug-iphoneos/MyApp.build/Objects-normal/arm64/Router.o in '/Users/.../Library/Developer/Xcode/DerivedData/MyApp-euxwyncffackymerzuntbjccezyq/Build/Intermediates.noindex/MyApp.build/Debug-iphoneos/MyApp.build/Objects-normal/arm64/Router.o'; file cannot be open()ed, errno=2 path=/Users/.../Library/Developer/Xcode/DerivedData/MyApp-euxwyncffackymerzuntbjccezyq/Build/Intermediates.noindex/MyApp.build/Debug-iphoneos/MyApp.build/Objects-normal/arm64/AccountRouter.o in '/Users/.../Library/Developer/Xcode/DerivedData/MyApp-euxwyncffackymerzuntbjccezyq/Build/Intermediates.noindex/MyApp.build/Debug-iphoneos/MyApp.build/Objects-normal/arm64/AccountRouter.o'; file cannot be open()ed, errno=2 path=/Users/.../Library/Developer/Xcode/DerivedData/MyApp-euxwyncffackymerzuntbjccezyq/Build/Intermediates.noindex/MyApp.build/Debug-iphoneos/MyApp.build/Objects-normal/arm64/AlertRouter.o in '/Users/.../Library/Developer/Xcode/DerivedData/MyApp-euxwyncffackymerzuntbjccezyq/Build/Intermediates.noindex/MyApp.build/Debug-iphoneos/MyApp.build/Objects-normal/arm64/AlertRouter.o'; file cannot be open()ed, errno=2 path=/Users/.../Library/Developer/Xcode/DerivedData/MyApp-euxwyncffackymerzuntbjccezyq/Build/Intermediates.noindex/MyApp.build/Debug-iphoneos/MyApp.build/Objects-normal/arm64/AlarmRouter.o in '/Users/.../Library/Developer/Xcode/DerivedData/MyApp-euxwyncffackymerzuntbjccezyq/Build/Intermediates.noindex/MyApp.build/Debug-iphoneos/MyApp.build/Objects-normal/arm64/AlarmRouter.o' (The '…’ is just me obfuscating the real name) I’ve checked the paths. The file are here and I can open them. I tried cleaning the project, removing every derived data. I removed every dependencies (cocoapods &amp; SPM). I’m using Tuist, so I fully cleaned the project and recreated it from scratch. Then I thought it might be an issue with my Xcode installation, so I tried running the project on another machine, I still get the same error every time. Anyone has a clue on what’s happening?

Hi, the documentation says that an application bundle for Mac OS X can have a Frameworks folder within Contents. Using a framework for console applications (no bundle) and GUI applications (bundle), I cannot load the console applications anymore on Ventura. Prior to Ventora I have tested and ran both on Mojave or earlier - I am not sure. To fix the issue, I have moved the frameworks within the application bundle to match the rpath for /Users/lothar/Library/Frameworks when I place the console into /Users/lothar/bin, the same rpath for application bundles works for those within the bin folder. Can I publish an application bundle with that modified layout or do I have to expect getting problems and do rather a Symlink pointing from /Users/lothar/Frameworks to /Users/lothar/Library/Frameworks? Thanks, Lothar

I am developing a simple camera JNI interface program in Objc. I managed to compile. But I get the following link error. I use the following command. Is there anything I can add to solve this problem? Note that I use Intel MacMini. g++ -framework Foundation -framework AVFoundation CameraMacOS.m Undefined symbols for architecture x86_64: "_CMVideoFormatDescriptionGetDimensions", referenced from: _openCamera in CameraMacOS-517c44.o _listWebcamNamesAndSizes in CameraMacOS-517c44.o "_CVPixelBufferGetBaseAddress", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o "_CVPixelBufferGetBytesPerRow", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o "_CVPixelBufferGetHeight", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o "_CVPixelBufferGetWidth", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o "_CVPixelBufferLockBaseAddress", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o "_CVPixelBufferUnlockBaseAddress", referenced from: -[CaptureDelegate captureOutput:didFinishProcessingPhoto:error:] in CameraMacOS-517c44.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

I have a multi-platform application made with Delphi which uses FTDI D2XX drivers. All is well in other platforms but i have this issue in MacOS when i try to start the application: Termination Reason: Namespace DYLD, Code 1 Library missing Library not loaded: libftd2xx.dylib Referenced from: <CD2148C0-F76F-35D5-8E65-2BE51F201302> /Users/USER/*/USB_Editor.app/Contents/MacOS/USB_Editor Reason: tried: 'libftd2xx.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibftd2xx.dylib' (no such file), 'libftd2xx.dylib' (no such file), '//libftd2xx.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS//libftd2xx.dylib' (no such file), '//libftd2xx.dylib' (no such file) (terminated at launch; ignore backtrace) If i try to run the executable i get a similar error which includes the users/user folder in the paths specified above. So if i copy libftd2xx.dylib to users/user the app can start from the executable and the USB library works well. The library is bundled in Contents/Framework as this seems to be the best (or only) accepted practice. Btw the app only starts during deployment if the library is found in Contents/MacOS. Library version is the most recent from FTDI site for the ARM architecture and followed their instructions to install. If i try the otool command on the library i get this: otool -L libftd2xx.dylib libftd2xx.dylib: libftd2xx.dylib (compatibility version 1.1.0, current version 1.4.30) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2202.0.0) I'm a Mac user since last week so my knowledge of the system is not so good yet (:

I have a Swift Package that includes XCFrameworks which are exported as binary targets. If I include any of the product in Frameworks and Libraries section of a notification service extension target, build succeeds while the extension crashes with dynamic linker error: Library not loaded: @rpath/MoEngageRichNotification.framework/MoEngageRichNotification My workaround is to include the same product in app target's Frameworks and Libraries section and add @executable_path/../../Frameworks to LD_RUNPATH_SEARCH_PATHS settings for extension target. Is this a known limitation of XCode when using SPM?

[MacOS Sequoia.] I am tracking down a problem where I am linking to libboringssl.dylib even though I am statically linking openssl. In Xcode debugger, 'Show Library info' shows this: But there is no such file as /usr/lib/libboringssl.dylib Whats going on?

Hi, I'm producing a dylib that another developer is trying to link with an ffmpeg plugin, building on Sequoia (this was not an issue prior to upgrading the OS). The error is: ld: Shared cache eligible dylib cannot link to ineligible dylib '@rpath/libme.dylib'. Remove link to ineligible dylib, fix its eligibility, or opt out of the shared cache using the build setting 'LD_SHARED_CACHE_ELIGIBLE=NO' (or linker flag '-not_for_dyld_shared_cache') clang: error: linker command failed with exit code 1 (use -v to see invocation) So, simple question - how do I "fix my dylib's eligibility"? I can't seem to find much info about this online. Thanks, Jeff

Hi, I am encountering a linking issue with a project for an iOS .NET MAUI application that I am developing using Visual Studio 17.11.4. This project includes a custom static library (.a). The custom static library (.a) depends on the libxml2 library. However, it appears that libxml2 is not included in Xcode 15.4 (Sonoma OS), resulting in the following error: error : Undefined symbols for architecture arm64: error : "_xmlBufferCreate", referenced from: .... I have set the following additional arguments for compilation: -cxx -gcc_flags "-lz -lxml2". Despite my efforts to install libxml2 using Homebrew, I have not been successful. Could you please advise on how I can resolve this issue? Specifically, what is the path that Xcode uses to include libxml2?

Hi, I have an issue with linker as well. I am building a IBM MQ driver using Erlang driver. It is building ok in Linux x64/Arm64 but doesn't build in macOS Arm64. Can you help please. e072513@VL-K4YR0QX62K c_src % gcc -I /opt/homebrew/Cellar/erlang@26/26.2.5/lib/erlang/usr/include -I /opt/mqm/inc -shared -fPIC -L /opt/mqm/lib64 -L /opt/homebrew/Cellar/erlang@26/26.2.5/lib/erlang/lib/erl_interface-5.5.1/lib -lei -lmqic_r -lpthread mq_series_drv.c -o mq_series_drv.so -v Apple clang version 16.0.0 (clang-1600.0.26.3) Target: arm64-apple-darwin23.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1 -triple arm64-apple-macosx14.0.0 -Wundef-prefix=TARGET_OS_ -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -Werror=implicit-function-declaration -emit-obj -mrelax-all -dumpdir mq_series_drv.so- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name mq_series_drv.c -mrelocation-model pic -pic-level 2 -mframe-pointer=non-leaf -fno-strict-return -ffp-contract=on -fno-rounding-math -funwind-tables=1 -fobjc-msgsend-selector-stubs -target-sdk-version=15.0 -fvisibility-inlines-hidden-static-local-var -fno-modulemap-allow-subdirectory-search -target-cpu apple-m1 -target-feature +v8.5a -target-feature +aes -target-feature +crc -target-feature +dotprod -target-feature +fp-armv8 -target-feature +fp16fml -target-feature +lse -target-feature +ras -target-feature +rcpc -target-feature +rdm -target-feature +sha2 -target-feature +sha3 -target-feature +neon -target-feature +zcm -target-feature +zcz -target-feature +fullfp16 -target-abi darwinpcs -debugger-tuning=lldb -target-linker-version 1115.7.3 -v -fcoverage-compilation-dir=/Users/e072513/ips-tch-switch/_checkouts/mq_series/c_src -resource-dir /Library/Developer/CommandLineTools/usr/lib/clang/16 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -I /opt/homebrew/Cellar/erlang@26/26.2.5/lib/erlang/usr/include -I /opt/mqm/inc -I/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Library/Developer/CommandLineTools/usr/lib/clang/16/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -internal-externc-isystem /Library/Developer/CommandLineTools/usr/include -Wno-reorder-init-list -Wno-implicit-int-float-conversion -Wno-c99-designator -Wno-final-dtor-non-final-class -Wno-extra-semi-stmt -Wno-misleading-indentation -Wno-quoted-include-in-framework-header -Wno-implicit-fallthrough -Wno-enum-enum-conversion -Wno-enum-float-conversion -Wno-elaborated-enum-base -Wno-reserved-identifier -Wno-gnu-folding-constant -fdebug-compilation-dir=/Users/e072513/ips-tch-switch/_checkouts/mq_series/c_src -ferror-limit 19 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fmax-type-align=16 -fcommon -fcolor-diagnostics -clang-vendor-feature=+disableNonDependentMemberExprInCurrentInstantiation -fno-odr-hash-protocols -clang-vendor-feature=+enableAggressiveVLAFolding -clang-vendor-feature=+revert09abecef7bbf -clang-vendor-feature=+thisNoAlignAttr -clang-vendor-feature=+thisNoNullAttr -clang-vendor-feature=+disableAtImportPrivateFrameworkInImplementationError -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /var/folders/zw/xt5wvkzj43v_p458qgx16bxw0000gn/T/mq_series_drv-d90068.o -x c mq_series_drv.c clang -cc1 version 16.0.0 (clang-1600.0.26.3) default target arm64-apple-darwin23.6.0 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include" ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks" #include "..." search starts here: #include &lt;...&gt; search starts here: /opt/homebrew/Cellar/erlang@26/26.2.5/lib/erlang/usr/include /opt/mqm/inc /Library/Developer/CommandLineTools/usr/lib/clang/16/include /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include /Library/Developer/CommandLineTools/usr/include /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory) End of search list. "/Library/Developer/CommandLineTools/usr/bin/ld" -demangle -lto_library /Library/Developer/CommandLineTools/usr/lib/libLTO.dylib -no_deduplicate -dynamic -dylib -arch arm64 -platform_version macos 14.0.0 15.0 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mllvm -enable-linkonceodr-outlining -o mq_series_drv.so -L/opt/mqm/lib64 -L/opt/homebrew/Cellar/erlang@26/26.2.5/lib/erlang/lib/erl_interface-5.5.1/lib -L/usr/local/lib -lei -lmqic_r -lpthread /var/folders/zw/xt5wvkzj43v_p458qgx16bxw0000gn/T/mq_series_drv-d90068.o -lSystem /Library/Developer/CommandLineTools/usr/lib/clang/16/lib/darwin/libclang_rt.osx.a Undefined symbols for architecture arm64: "_driver_alloc", referenced from: _mq_drv_start in mq_series_drv-d90068.o _do_connect in mq_series_drv-d90068.o _do_put in mq_series_drv-d90068.o _do_get in mq_series_drv-d90068.o "_driver_async", referenced from: _do_connect in mq_series_drv-d90068.o _do_put in mq_series_drv-d90068.o _do_get in mq_series_drv-d90068.o "_driver_free", referenced from: _mq_drv_stop in mq_series_drv-d90068.o _ready_async in mq_series_drv-d90068.o _do_free in mq_series_drv-d90068.o "_driver_output", referenced from: _ready_async in mq_series_drv-d90068.o _error_bad_arg in mq_series_drv-d90068.o _return_error in mq_series_drv-d90068.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

iOS now has a pre-build closure optimization for launch, so how do I know if my app launches with a pre-build closure optimization? In what way can I check that my application has a pre-built closure at startup？

We recently started encountering a perplexing crash when we build our iOS application to device: Termination Reason: DYLD 1 Library missing Library not loaded: /usr/lib/libc++.1.dylib Referenced from: <2A9D8B8D-E81E-3FEC-A4B7-1EA4841CFC4F> /Volumes/VOLUME/*/Walmart.app/Walmart Reason: tried: '/usr/lib/libc++.1.dylib' (no such file), '/private/preboot/Cryptexes/OS/usr/lib/libc++.1.dylib' (no such file), '/usr/lib/libc++.1.dylib' (no such file, no dyld cache) (terminated at launch; ignore backtrace) Highlighted by Thread: 0 See attachment for full crash log. We've been spinning our wheels trying to understand why this could be happening. We've had the OTHER_LDFLAGS= -lc++ for some time now and we tried linking libc++.1.tbd to no avail. Any help? Walmart-2024-09-26-154332.ips

I'm trying to build an iOS project in command line via xcodebuild. OS: Mac OS 15.1 beta Xcode: Xcode 16 Creating a new iOS project and trying to run xcodebuild results in this error. No other dependencies, no frameworks added. ld: building for 'iOS', but linking in dylib (/Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/usr/lib/libobjc.A.tbd) built for 'macOS macCatalyst zippered(macOS/Catalyst)' My initial plan was to do this with a VisionOS project, but for some reason, I'm getting errors like this for both platforms and brand new projects. Any pointers as to what is referencing the MacOS SDK and how I can fix this would be helpful. Complete log: /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild -sdk iphoneos -configuration Release -scheme iphonedummy build CODE_SIGNING_ALLOWED=NO -verbose User defaults from command line: IDEPackageSupportUseBuiltinSCM = YES Build settings from command line: CODE_SIGNING_ALLOWED = NO SDKROOT = iphoneos18.0 Prepare packages ComputeTargetDependencyGraph note: Building targets in dependency order note: Target dependency graph (1 target) Target 'iphonedummy' in project 'iphonedummy' (no dependencies) GatherProvisioningInputs CreateBuildDescription // Removed a block for length. ExecuteExternalTool /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -v -E -dM -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS18.0.sdk -x c -c /dev/null // Removed another block for length. Build description signature: dc5e0c08dfce007b98c7bce87acea5fe Build description path: /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Intermediates.noindex/XCBuildData/dc5e0c08dfce007b98c7bce87acea5fe.xcbuilddata ClangStatCache /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang-stat-cache /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS18.0.sdk /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/SDKStatCaches.noindex/iphoneos18.0-22A3362-8ec3fe4dca91fa9a941eaa2d5faad0e4.sdkstatcache cd /Users/sravankaruturi/dev/iphonedummy/iphonedummy.xcodeproj /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang-stat-cache /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS18.0.sdk -o /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/SDKStatCaches.noindex/iphoneos18.0-22A3362-8ec3fe4dca91fa9a941eaa2d5faad0e4.sdkstatcache ProcessInfoPlistFile /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Products/Release-iphoneos/iphonedummy.app/Info.plist /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Intermediates.noindex/iphonedummy.build/Release-iphoneos/iphonedummy.build/empty-iphonedummy.plist (in target 'iphonedummy' from project 'iphonedummy') cd /Users/sravankaruturi/dev/iphonedummy builtin-infoPlistUtility /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Intermediates.noindex/iphonedummy.build/Release-iphoneos/iphonedummy.build/empty-iphonedummy.plist -producttype com.apple.product-type.application -genpkginfo /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Products/Release-iphoneos/iphonedummy.app/PkgInfo -expandbuildsettings -format binary -platform iphoneos -additionalcontentfile /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Intermediates.noindex/iphonedummy.build/Release-iphoneos/iphonedummy.build/assetcatalog_generated_info.plist -requiredArchitecture arm64 -o /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Products/Release-iphoneos/iphonedummy.app/Info.plist Ld /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Products/Release-iphoneos/iphonedummy.app/iphonedummy normal (in target 'iphonedummy' from project 'iphonedummy') cd /Users/sravankaruturi/dev/iphonedummy /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Xlinker -reproducible -target arm64-apple-ios18.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS18.0.sdk -Os -L/Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Intermediates.noindex/EagerLinkingTBDs/Release-iphoneos -L/Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Products/Release-iphoneos -F/Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Intermediates.noindex/EagerLinkingTBDs/Release-iphoneos -F/Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Products/Release-iphoneos -filelist /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Intermediates.noindex/iphonedummy.build/Release-iphoneos/iphonedummy.build/Objects-normal/arm64/iphonedummy.LinkFileList -Xlinker -rpath -Xlinker @executable_path/Frameworks -dead_strip -Xlinker -object_path_lto -Xlinker /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Intermediates.noindex/iphonedummy.build/Release-iphoneos/iphonedummy.build/Objects-normal/arm64/iphonedummy_lto.o -fobjc-link-runtime -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphoneos -L/usr/lib/swift -Xlinker -add_ast_path -Xlinker /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Intermediates.noindex/iphonedummy.build/Release-iphoneos/iphonedummy.build/Objects-normal/arm64/iphonedummy.swiftmodule -Xlinker -dependency_info -Xlinker /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Intermediates.noindex/iphonedummy.build/Release-iphoneos/iphonedummy.build/Objects-normal/arm64/iphonedummy_dependency_info.dat -o /Users/sravankaruturi/Library/Developer/Xcode/DerivedData/iphonedummy-bwpzemojmpkzehhhkxqtjearnxkl/Build/Products/Release-iphoneos/iphonedummy.app/iphonedummy ld: building for 'iOS', but linking in dylib (/Library/Developer/CommandLineTools/SDKs/MacOSX15.0.sdk/usr/lib/libobjc.A.tbd) built for 'macOS macCatalyst zippered(macOS/Catalyst)' clang: error: linker command failed with exit code 1 (use -v to see invocation)

If I use the manual merge option with a mergeable library in debug mode, the app crashes on the device only. Here's what I found when debugging this issue. Problem situation 1 In the debug build, the linker does not find the type of the Meregeable Library. Explain the debugged result of Problem Situation 1 We have a type called UserAdDTO, which belongs to the B Framework. - In our project, B Framework and C Framework are mergeable libraries, and they are merged into A Framework. We are using Manual Merge in A Framework. When we build with the simulator, we link the UserAdDTO from CFramework.framework/CFramework in the app target. On the other hand, when I build with the device, I try to link it from AFramework.framework/AFramework, and I get the issue that UserAdDTO is not found. So, even if you output DYLD_PRINT_BINDINGS, the simulator build links to the C Framework to find the UserAdDTO, but the app links to the B Framework, causing a runtime crash. Problem situation 2 It is confirmed that only the device build does not copy the reexported binary. Detailed description of problem situation 2 If you compare the build messages from the device build with the build messages from the release build, both generate the reexported binaries of B and C Frameworks, but do not copy them to BFramework.framework and CFramework.framework. Instead, they copy the files in different paths. This appears to be a bug, and I'd like to ask you to confirm.

So I'm working on a large client app with lots of frameworks and modules which is is a mix of Xcode frameworks with 3rd party dependencies in CocoaPods and newer/converted SPM modules. Essentially CocoaPods is used to set the 3rd party dependencies on various Xcode frameworks, which also depend on each other via manual set dependencies, plus a bunch of SPM modules which are also manually added. It's a bit of a mess. The problem we encountered the other day started when I added a new protocol to one of the SPM modules. Nothing special about it, all types from Foundation and the app built and ran perfectly in simulator with a Debug build. However when we switched to building a Release build, it failed to link, logging an error indicating it could not resolve the new protocol in a number of the Xcode framework projects. The resolutions go like this: The Xcode app project has some manually added Xcode frameworks. Those frameworks have manually added dependencies on a second Xcode framework. That second framework has an SPM dependency on the module where my protocol lives. So Xcode App -> 1st Xcode framework -> 2nd Xcode framework -> SPM module. Now the 2nd Xcode framework directly uses my protocol from the SPM module. But the 1st Xcode framework neither uses or imports the SPM module. Yet the error we get when building for Release is that the 1st Framework is unable to resolve the protocol from the SPM module even though it's completely oblivious to it. My working theory is that something in the way a Release build works is insisting that when linking the 1st Xcode framework, it has to resolve the 2nd Xcode framework, which then has to resolve types from the SPM modules, but for some reason and only in a Release build, it's unable to. So our current workaround has been to add the SPM module as a dependency to all 1st level Xcode frameworks that have the 2nd Xcode framework as a dependency. That works because when linking the 1st Xcode framework, it has a direct reference to the module even though the code never imports anything from it. Does this should correct?

ld: symbol(s) not found for architecture arm64 clang++: error: linker command failed with exit code 1 (use -v to see invocation) Undefined symbol: nominal type descriptor for CoreGraphics.CGFloat Undefined symbol: type metadata for CoreGraphics.CGFloat Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.BinaryFloatingPoint in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.Encodable in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.FloatingPoint in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.Hashable in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.Comparable in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.Equatable in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.Decodable in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.SignedNumeric in CoreGraphics

We have updated our cross-platform applications to support iOS 18 and are in the final stages of releasing versions built with MacCatalyst. After merging the MacCatalyst changes with those for iOS 18, we are now required to build the app using Xcode 16. However, since transitioning to Xcode 16, the app builds successfully but crashes immediately on startup with the following error: dyld[45279]: Symbol not found: _$sSo22VNFaceLandmarkRegion2DC6VisionE16normalizedPointsSaySo7CGPointVGvg Referenced from: <211097A0-6612-3A9A-80B5-AE12915EBA2A> /Users/***/Library/Developer/Xcode/DerivedData/DM_iOS_Apps-gzpzdsacfldxxwclyngreqkbhtey/Build/Products/Debug-maccatalyst/MyApp.app/Contents/Frameworks/Filters_MyApp.framework/Versions/A/Filters_MyApp Expected in: <50DB755E-C83C-3FC7-A0BB-9C4DF9FEA374> /System/Library/Frameworks/Vision.framework/Versions/A/Vision This crash occurs only when building the app with Xcode 16 for MacCatalyst on macOS 14.6.1. On iOS and macOS 15, it functions as expected, and it also worked prior to the iOS 18 changes, which are independent of the Vision framework code, when building with Xcode 15. Here are the environment details where the error occurs: Xcode Version: Xcode 16.0 (16A242d) macOS Version: macOS Sonoma 14.6.1 And the setup where it works: Xcode Version: Xcode 16.0 (16A242d) macOS Version: macOS Sequoia 15.0 Additionally, attempting to implement a workaround using pointsInImage(imageSize:) resulted in a similar issue, where the symbol for this method is also missing. Is this a known issue? Are there any workarounds or fixes available? We have already submitted this issue as feedback (FB15164375), along with a demo project to illustrate the problem.