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

I have reference some related post for this issue: https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes#Foundation https://developer.apple.com/forums/thread/762711 Unfortunately, I'm facing the similar issues even though using Xcode Version 16.2 (16C5032a). we have the following build environment: Xcode version: Xcode 16.2 (16C5032a) macOS Version: macOS 14.7.4 (23H420) Everything builds and install fine. But when attempting to plug on Device on macOS 14.7.4 it crashes immediately with what appears to be a missing Foundation symbol. Crashed Thread: 0 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace DYLD, Code 4 Symbol missing Symbol not found: __ZThn48_N21IOUserNetworkEthernet25registerEthernetInterfaceE10ether_addrPP24IOUserNetworkPacketQueuejP29IOUserNetworkPacketBufferPoolS5_ Referenced from: <ECE57ABF-0633-3C3B-8427-FB25CC706343> /Library/SystemExtensions/*/com.asix.dext.pciedevice Expected in: <CDEB3490-B1E0-3D60-80CE-59C0682A4B03> /System/DriverKit/System/Library/Frameworks/NetworkingDriverKit.framework/NetworkingDriverKit (terminated at launch; ignore backtrace) Thread 0 Crashed: 0 dyld 0x1041da4c8 __abort_with_payload + 8 1 dyld 0x1041e50cc abort_with_payload_wrapper_internal + 104 2 dyld 0x1041e5100 abort_with_payload + 16 3 dyld 0x1041767f0 dyld4::halt(char const*, dyld4::StructuredError const*) + 304 4 dyld 0x1041732ec dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3888 5 dyld 0x104171ef4 start + 1868 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000000000000006 x1: 0x0000000000000004 x2: 0x000000016bdd2810 x3: 0x0000000000000172 x4: 0x000000016bdd2410 x5: 0x0000000000000000 x6: 0x000000016bdd1400 x7: 0x000000016bdd1460 x8: 0x0000000000000020 x9: 0x000000016bdd237c x10: 0x000000000000000a x11: 0x0000000000000000 x12: 0x0000000000000038 x13: 0x0000000000000000 x14: 0x0000000188e77f9d x15: 0x0000000000008000 x16: 0x0000000000000209 x17: 0x000000010416f37c x18: 0x0000000000000000 x19: 0x0000000000000000 x20: 0x000000016bdd2410 x21: 0x0000000000000172 x22: 0x000000016bdd2810 x23: 0x0000000000000004 x24: 0x0000000000000006 x25: 0x00000000000000a8 x26: 0x000000016bdd32d8 x27: 0x000000010405e090 x28: 0x0000000000000001 fp: 0x000000016bdd23e0 lr: 0x00000001041e50cc sp: 0x000000016bdd23a0 pc: 0x00000001041da4c8 cpsr: 0x80001000 far: 0x0000000000000000 esr: 0x56000080 Address size fault Binary Images: 0x10416c000 - 0x1041f7fff dyld (*) <4fe051cf-29dc-3f02-890b-33144fa09253> /usr/lib/dyld 0x10402c000 - 0x10403ffff com.asix.dext.pciedevice (0.1.6) <ece57abf-0633-3c3b-8427-fb25cc706343> /Library/SystemExtensions/*/com.asix.dext.pciedevice 0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ??? External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 0 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=8612K resident=0K(0%) swapped_out_or_unallocated=8612K(100%) Writable regions: Total=12.2M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=12.2M(100%) Is it expected that this should work? Is this a known issue? Is there any workaround for it? Should I file feedback or a DTS?

hi, I have offered to help port a custom debug tool that "revives" a process from a core file. It currently works on Linux and Windows and I would like to help port it to macOS. On Linux, prelink is used to load a dynamic library at a specific addrress (to match its location in corefile). On Windows, editbin is used. Is there an off the shelf tool that loads a dylib on macOS at a specified address? I tried to research this topic and I see: dylibs on macOS are position independent, though apparently it is possible to build a position dependent lib (but the note doesn't say how) there is a slide value that adjust base address of a dylib (but I can not find much actual info on how exactly to use it) prebinding (deprecated?) I feel like I am starting to veer off into fun topics, like dylib hijacking and implementing custom dylib loaders (DyldDeNeuralyzer). As much as I enjoy going off main path sometimes, can someone help set me back on the main path? thanks!

good.load_commands.txt I bad.load_commands.txt have two dylibs built with different parameters on different machines. Both have the same dependency(@rpath/libc++.dylib). When @rpath/libc++.dylib is missing, one of them can still be laoded via dlopen with RTLD_NOW, and I want to understand why. Additional infomation: Both dylibs are the same architecture(arm64) They had identical LC_RPATH settings. But I've removed them via install_name_tool just to simplify the problem. Through otool -l to view load commands, I can't find any differnent between them except they had different libSystem.B.dylib version. And then,I through setting DYLD_PRINT_SEARCHING=1 and load them. I found differenes in their dependency search processes, but' I'm unsure what causes this discrepancy. these are outputs: ./a.out libchrome_zlib.dylib.good dyld[37001]: find path "/usr/lib/libc++.1.dylib" dyld[37001]: possible path(original path on disk): "/usr/lib/libc++.1.dylib" dyld[37001]: possible path(cryptex prefix): "/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libc++.1.dylib" dyld[37001]: possible path(original path): "/usr/lib/libc++.1.dylib" dyld[37001]: found: dylib-from-cache: (0x000A) "/usr/lib/libc++.1.dylib" dyld[37001]: find path "/usr/lib/libSystem.B.dylib" dyld[37001]: possible path(original path on disk): "/usr/lib/libSystem.B.dylib" dyld[37001]: possible path(cryptex prefix): "/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib" dyld[37001]: possible path(original path): "/usr/lib/libSystem.B.dylib" dyld[37001]: found: dylib-from-cache: (0x00AB) "/usr/lib/libSystem.B.dylib" dyld[37001]: find path "libchrome_zlib.dylib.good" dyld[37001]: possible path(original path on disk): "libchrome_zlib.dylib.good" dyld[37001]: found: dylib-from-disk: "libchrome_zlib.dylib.good" dyld[37001]: find path "@rpath/libc++.dylib" dyld[37001]: possible path(default fallback): "/usr/local/lib/libc++.dylib" dyld[37001]: possible path(default fallback): "/usr/lib/libc++.dylib" dyld[37001]: found: dylib-from-cache: (0x000A) "/usr/lib/libc++.dylib" ./a.out libchrome_zlib.dylib.bad dyld[41256]: find path "/usr/lib/libc++.1.dylib" dyld[41256]: possible path(original path on disk): "/usr/lib/libc++.1.dylib" dyld[41256]: possible path(cryptex prefix): "/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libc++.1.dylib" dyld[41256]: possible path(original path): "/usr/lib/libc++.1.dylib" dyld[41256]: found: dylib-from-cache: (0x000A) "/usr/lib/libc++.1.dylib" dyld[41256]: find path "/usr/lib/libSystem.B.dylib" dyld[41256]: possible path(original path on disk): "/usr/lib/libSystem.B.dylib" dyld[41256]: possible path(cryptex prefix): "/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib" dyld[41256]: possible path(original path): "/usr/lib/libSystem.B.dylib" dyld[41256]: found: dylib-from-cache: (0x00AB) "/usr/lib/libSystem.B.dylib" dyld[41256]: find path "libchrome_zlib.dylib.bad" dyld[41256]: possible path(original path on disk): "libchrome_zlib.dylib.bad" dyld[41256]: found: dylib-from-disk: "libchrome_zlib.dylib.bad" dyld[41256]: find path "@rpath/libc++.dylib" dyld[41256]: not found: "@rpath/libc++.dylib" dlopen failed: dlopen(libchrome_zlib.dylib.bad, 0x0002): Library not loaded: @rpath/libc++.dylib Referenced from: <42E93041-7B58-365B-9967-04AE754AA9F0> /Users/jiangzh/dlopen/libchrome_zlib.dylib.bad Reason: no LC_RPATH's found

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

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

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

Our app supports iOS12 as the minimum OS and we embed a framework with iOS15 minimum support. Naturally we weak-link it and use #available(iOS 15, ) to guard accesses to its symbols. On iOS12.5.7 the framework is completely ignored and the app works fine. On iOS13.3.1 however we get to see this error: Termination Description: DYLD, dependent dylib '/System/Library/Frameworks/AVFAudio.framework/AVFAudio' not found for '/private/var/containers/Bundle/Application/08DA2D93-4DC2-4523-98AF-FD52884989AE/<OUR_APP>.app/Frameworks/<FRAMEWORK>.framework/<FRAMEWORK>', tried but didn't find: '/System/Library/Frameworks/AVFAudio.framework/AVFAudio' '/System/Library/Frameworks/AVFAudio.framework/AVFAudio' has a dependency on AVFAudio which is available only since iOS 14.5 so it makes sense it wouldn;t be able to find it but what's bothering us is why does dyld even try loading the 's dependencies instead of just ignoring it? Could this be a bug on 13.3.1? Unfortunately at this time we don't have other iOS13 phones to test with. The 'LC_BUILD_VERSION' command sure enough seems valid:: Load command 10 cmd LC_BUILD_VERSION cmdsize 32 platform 2 minos 15.0 sdk 17.0 ntools 1 tool 3 version 1015.7

When I run app, it works on iOS16+ device. But when I run on iOS15 device just working on debug mode, if I run release or profile modeI got runtime error: Log: (lldb) dyld[4928]: Symbol not found: (_objc_claimAutoreleasedReturnValue) Referenced from: '/private/var/containers/Bundle/Application/C724D7C6-82FA-4AF3-AE83-EC035B4429A5/Runner.app/Frameworks/geolocator_apple.framework/geolocator_apple' Expected in: '/usr/lib/libobjc.A.dylib' thread #1, stop reason = signal SIGABRT frame #0: 0x0000000106cbb2cc dyld`__abort_with_payload + 8 dyld`__abort_with_payload: -&amp;gt; 0x106cbb2cc &amp;lt;+8&amp;gt;: b.lo 0x106cbb2e8 ; &amp;lt;+36&amp;gt; 0x106cbb2d0 &amp;lt;+12&amp;gt;: stp x29, x30, [sp, #-0x10]! 0x106cbb2d4 &amp;lt;+16&amp;gt;: mov x29, sp 0x106cbb2d8 &amp;lt;+20&amp;gt;: bl 0x106c8164c ; cerror_nocancel Target 0: (Runner) stopped. Flutter doctor : Doctor summary (to see all details, run flutter doctor -v): [✓] Flutter (Channel stable, 3.29.2, on macOS 15.2 24C101 darwin-arm64, locale en-VN) [✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0) [✓] Xcode - develop for iOS and macOS (Xcode 16.2) [✓] Chrome - develop for the web [✓] Android Studio (version 2024.2) [✓] VS Code (version 1.97.2)

I work on an iOS app, written in Objective-C and C++, that uses a static library. I build this library using a Run Script in Build Phases in Xcode. This is a fat library, containing arm64 code built for iPhoneOS, and x86_64 code built for iPhoneSimulator. I'm trying to figure out how to create an arm64 iPhoneSimulator build of my app, and I'm running into a problem. If I simply enable arm64 debug builds, I get an error message saying "building for iOS Simulator, but linking in object file built for iOS", indicating that the arm64 iPhoneOS code in the library is not compatible with an arm64 iPhoneSimulator target. Now, I can build the library as arm64 for iPhoneSimulator, but that means I'll have to build a separate library for the simulator build, since lipo won't combine arm64 iPhoneOS and arm64 iPhoneSimulator builds in one file. My question: how can I get Xcode to link with a different library for iPhoneSimulator builds than for iPhoneOS builds? All I can come up with is to use completely separate targets for debugging in the simulator vs. debugging on a real device, but that seems ugly. (It would be even better if I could use the same library for both arm64 iPhoneSimulator and iPhoneOS builds. The library in question is a math library which makes no system calls, so I think the same code should be usable for both builds, if only I could get the linker to allow that.)

How do I get rid of this CLI error? Thanks dyld[35085]: symbol '__ZTINSt3__13pmr15memory_resourceE' missing from root that overrides /usr/lib/libc++.1.dylib. Use of that symbol in /System/Library/PrivateFrameworks/caulk.framework/Versions/A/caulk is being set to 0xBAD4007.

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

We are renaming the project and a Static Library the is critical to the operation on the app is not found during compiling. We have the same project working fine. We have reviewed the project.pbxproj file and searched for erroneous linking, reviewed the Target settings and there is nothing obviously wrong. (Copied and secured the original) Typically workflow is: Clean Delete Derived Data dir D/l Swift Packages Build/Run The team has many years using Xcode / Swift and the project and this is not clear how to resolve. We have scoured SO and the solutions do not apply. Facts: -No cocoapods -Search Paths all set Linker all set Thoughts?

I'm attempting to create a proof of concept of a static library, distributed as an XCFramework, which has two local XCFramework dependencies. The reason for this is because I'm working to provide a single statically linked library to a customer, instead of providing them with the static library plus the two dependencies. The Issue With a fairly simple example project, I'm not able to access any code from the static library without the complier throwing a "No such module" error and saying that it cannot find one of the dependent modules. Project Layout I have an example project that has some example targets with basic example code. Example Project on Github Target: FrameworkA Mach-0 Type: Dynamic Build Mergable Library: Yes Skip Install: No Build Libraries For Distribution: Yes Target: FrameworkB Mach-0 Type: Dynamic Build Mergable Library: Yes Skip Install: No Build Libraries For Distribution: Yes XCFrameworks are being generated from these two targets using Apple's recommendations. I've verified that the mergable metadata is present in both framework's Info.plist files. Each exposes a single struct which will return an example String. Finally I have my SDK target: Target: ExampleKit Mach-0 Type: Static Build Mergable Library: No Create Merged Binary: Manual Skip Install: No Build Libraries For Distribution: Yes The two .xcframework files are in the Target's folder structure as well. The "Link Binary With Libraries" build phase includes them and they're Required. Inside of the ExampleKit target, I have a single public struct which has two static properties which return the example strings from FrameworkA and FrameworkB. I then have another script which generates an XCFramework from this target. Expectations Based on Apple's documentation and the "Meet Mergable Libraries" WWDC session I would expect that I could make a simple iOS app, link the ExampleKit.xcframework, import ExampleKit inside of a file, and be able to access the single public struct present in ExampleKit. Unfortunately, all I get is "No such module FrameworkA". I would expect that FrameworkA and FrameworkB would have been merged into ExampleKit? I'm really unsure of where to go from here in debugging this. And more importantly, is this even a possible thing to do?

Hi. I have a xcframework that has a dependency on 'RxSwift' and 'RxCocoa'. I deployed it using SPM by embedding it in a Swift Package. However when I import swift package into another project, I keep getting the following error: "Missing required module 'RxCocoaRuntime" How can I fix this? Below are the steps to reproduce the error. Steps Create Xcode proejct, make a dependency on 'RxSwift' and 'RxCocoa' (no matter doing it through tuist or cocoapods) Create XCFramework from that proejct. (I used commands below) xcodebuild archive \ -workspace SimpleFramework.xcworkspace \ -scheme "SimpleFramework" \ -destination "generic/platform=iOS" \ -archivePath "./SimpleFramework-iphoneos.xcarchive" \ -sdk iphoneos \ SKIP_INSTALL=NO \ BUILD_LIBRARY_FOR_DISTRIBUTION=YES xcodebuild archive \ -workspace SimpleFramework.xcworkspace \ -scheme "SimpleFramework" \ -archivePath "./SimpleFramework-iphonesimulator.xcarchive" \ -sdk "iphonesimulator" \ SKIP_INSTALL=NO \ BUILD_LIBRARY_FOR_DISTRIBUTION=YES xcodebuild -create-xcframework \ -framework "./SimpleFramework-iphoneos.xcarchive/Products/Library/Frameworks/SimpleFramework.framework" \ -framework "./SimpleFramework-iphonesimulator.xcarchive/Products/Library/Frameworks/SimpleFramework.framework" \ -output "./SimpleFramework.xcframework" Embed in Swift Package, and deploy. // swift-tools-version: 6.0 // The swift-tools-version declares the minimum version of Swift required to build this package. import PackageDescription let package = Package( name: "SimplePackage", platforms: [.iOS(.v16)], products: [ .library( name: "SimplePackage", targets: ["SimplePackage"]), ], dependencies: [ .package(url: "https://github.com/ReactiveX/RxSwift", from: "6.8.0") ], targets: [ .binaryTarget( name: "SimpleFramework", path: "Sources/SimpleFramework.xcframework" ), .target( name: "SimplePackage", dependencies: [ "SimpleFramework", "RxSwift", .product(name: "RxCocoa", package: "RxSwift") ] ) ] ) Download Swift Package in another project and import module. I resolved this by removing dependencies from the Swift Package, downloading package in another project, and fetching dependencies by cocoapods. Thist works, but I don't want to use another dependency manager while using SPM. Development Environment CPU : Apple M4 Max MacOS : Sequoia 15.3 Xcode : 16.2

I’m running into an issue while implementing JournalingSuggestions with Xcode 16.2 and the iOS 18 simulator. My code builds and runs fine on a physical device, but it consistently crashes on the simulator and in Xcode previews. I’ve tried several workarounds, including weak linking and solutions from this post (746843), but I’m still hitting a wall. Here’s what’s happening: I get a warning: JournalingSuggestions is not available when building for iOS Simulator. This is followed by a build error: Linker command failed with exit code 1 (use -v to see invocation). What I’ve Tried: Weak linking the JournalingSuggestions framework. Applying fixes from this post (746843), such as cleaning the build folder and using weak link. Deleting Derived Data and rebuilding. Testing on a physical device (works fine). My Setup: Xcode Version: 16.2 Simulator: iOS 18 Build Success: Works on physical device, fails on simulator/preview Code: #if canImport(JournalingSuggestions) import JournalingSuggestions #endif ... var suggestionButton: some View { #if canImport(JournalingSuggestions) #if !targetEnvironment(simulator) if #available(iOS 17.2, *) { return AnyView(journalingSuggestionsPickerButton) } #endif return AnyView(disabledSuggestionButton) #else return AnyView(disabledSuggestionButton) #endif }

I have command line tools installed: % pkgutil --pkg-info=com.apple.pkg.CLTools_Executables package-id: com.apple.pkg.CLTools_Executables version: 16.2.0.0.1.1733547573 volume: / location: / install-time: 1739567437 Thus clang is installed here: % whereis g++ g++: /usr/bin/g++ I also have installed gcc from homebrew: % /opt/homebrew/bin/g++-14 --version g++-14 (Homebrew GCC 14.2.0_1) 14.2.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. However, I still cannot compile any c++ code, even the simplest one: #include &lt;iostream&gt; using namespace std; int main() { cout &lt;&lt; "Hello World!" &lt;&lt; endl; return 0; } It returned this error: % /opt/homebrew/bin/g++-14 ~/Downloads/try.cpp ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/lib/libSystem.tbd' for architecture arm64 collect2: error: ld returned 1 exit status It seems to be command line tools related. But I've already installed the most recent version of CLT and gcc. Additionally, clang can compile the same code: % /usr/bin/g++ ~/Downloads/try.cpp % ./a.out Hello World! What else shall I do to make this g++ compiler work?

This posts collects together a bunch of information about the symbols found in a Mach-O file. It assumes the terminology defined in An Apple Library Primer. If you’re unfamiliar with a term used here, look there for the definition. If you have any questions or comments about this, start a new thread in the Developer Tools & Services > General topic area and tag it with Linker. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Understanding Mach-O Symbols Every Mach-O file has a symbol table. This symbol table has many different uses: During development, it’s written by the compiler. And both read and written by the linker. And various other tools. During execution, it’s read by the dynamic linker. And also by various APIs, most notably dlsym. The symbol table is an array of entries. The format of each entry is very simple, but they have been used and combined in various creative ways to achieve a wide range of goals. For example: In a Mach-O object file, there’s an entry for each symbol exported to the linker. In a Mach-O image, there’s an entry for each symbol exported to the dynamic linker. And an entry for each symbol imported from dynamic libraries. Some entries hold information used by the debugger. See Debug Symbols, below. Examining the Symbol Table There are numerous tools to view and manipulate the symbol table, including nm, dyld_info, symbols, strip, and nmedit. Each of these has its own man page. A good place to start is nm: % nm Products/Debug/TestSymTab U ___stdoutp 0000000100000000 T __mh_execute_header U _fprintf U _getpid 0000000100003f44 T _main 0000000100008000 d _tDefault 0000000100003ecc T _test 0000000100003f04 t _testHelper Note In the examples in this post, TestSymTab is a Mach-O executable that’s formed by linking two Mach-O object files, main.o and TestCore.o. There are three columns here, and the second is the most important. It’s a single letter indicating the type of the entry. For example, T is a code symbol (in Unix parlance, code is in the text segment), D is a data symbol, and so on. An uppercase letter indicates that the symbol is visible to the linker; a lowercase letter indicates that it’s internal. An undefined (U) symbol has two potential meanings: In a Mach-O image, the symbol is typically imported from a specific dynamic library. The dynamic linker connects this import to the corresponding exported symbol of the dynamic library at load time. In a Mach-O object file, the symbol is undefined. In most cases the linker will try to resolve this symbol at link time. Note The above is a bit vague because there are numerous edge cases in how the system handles undefined symbols. For more on this, see Undefined Symbols, below. The first column in the nm output is the address associated with the entry, or blank if an address is not relevant for this type of entry. For a Mach-O image, this address is based on the load address, so the actual address at runtime is offset by the slide. See An Apple Library Primer for more about those concepts. The third column is the name for this entry. These names have a leading underscore because that’s the standard name mangling for C. See An Apple Library Primer for more about name mangling. The nm tool has a lot of formatting options. The ones I use the most are: -m — This prints more information about each symbol table entry. For example, if a symbol is imported from a dynamic library, this prints the library name. For a concrete example, see A Deeper Examination below. -a — This prints all the entries, including debug symbols. We’ll come back to that in the Debug Symbols section, below. -p — By default nm sorts entries by their address. This disables that sort, causing nm to print the entries in the order in which they occur in the symbol table. -x — This outputs entries in a raw format, which is great when you’re trying to understand what’s really going on. See Raw Symbol Information, below, for an example of this. A Deeper Examination To get more information about each symbol table, run nm with the -m option: % nm -m Products/Debug/TestSymTab (undefined) external ___stdoutp (from libSystem) 0000000100000000 (__TEXT,__text) [referenced dynamically] external __mh_execute_header (undefined) external _fprintf (from libSystem) (undefined) external _getpid (from libSystem) 0000000100003f44 (__TEXT,__text) external _main 0000000100008000 (__DATA,__data) non-external _tDefault 0000000100003ecc (__TEXT,__text) external _test 0000000100003f04 (__TEXT,__text) non-external _testHelper This contains a world of extra information about each entry. For example: You no longer have to remember cryptic single letter codes. Instead of U, you get undefined. If the symbol is imported from a dynamic library, it gives the name of that dynamic library. Here we see that _fprintf is imported from the libSystem library. It surfaces additional, more obscure information. For example, the referenced dynamically flag is a flag used by the linker to indicate that a symbol is… well… referenced dynamically, and thus shouldn’t be dead stripped. Undefined Symbols Mach-O’s handling of undefined symbols is quite complex. To start, you need to draw a distinction between the linker (aka the static linker) and the dynamic linker. Undefined Symbols at Link Time The linker takes a set of files as its input and produces a single file as its output. The input files can be Mach-O images or dynamic libraries [1]. The output file is typically a Mach-O image [2]. The goal of the linker is to merge the object files, resolving any undefined symbols used by those object files, and create the Mach-O image. There are two standard ways to resolve an undefined symbol: To a symbol exported by another Mach-O object file To a symbol exported by a dynamic library In the first case, the undefined symbol disappears in a puff of linker magic. In the second case, it records that the generated Mach-O image depends on that dynamic library [3] and adds a symbol table entry for that specific symbol. That entry is also shown as undefined, but it now indicates the library that the symbol is being imported from. This is the core of the two-level namespace. A Mach-O image that imports a symbol records both the symbol name and the library that exports the symbol. The above describes the standard ways used by the linker to resolve symbols. However, there are many subtleties here. The most radical is the flat namespace. That’s out of scope for this post, because it’s a really bad option for the vast majority of products. However, if you’re curious, the ld man page has some info about how symbol resolution works in that case. A more interesting case is the -undefined dynamic_lookup option. This represents a halfway house between the two-level namespace and the flat namespace. When you link a Mach-O image with this option, the linker resolves any undefined symbols by adding a dynamic lookup undefined entry to the symbol table. At load time, the dynamic linker attempts to resolve that symbol by searching all loaded images. This is useful if your software works on other Unix-y platforms, where a flat namespace is the norm. It can simplify your build system without going all the way to the flat namespace. Of course, if you use this facility and there are multiple libraries that export that symbol, you might be in for a surprise! [1] These days it’s more common for the build system to pass a stub library (.tbd) to the linker. The effect is much the same as passing in a dynamic library. In this discussion I’m sticking with the old mechanism, so just assume that I mean dynamic library or stub library. If you’re unfamiliar with the concept of a stub library, see An Apple Library Primer. [2] The linker can also merge the object files together into a single object file, but that’s relatively uncommon operation. For more on that, see the discussion of the -r option in the ld man page. [3] It adds an LC_LOAD_DYLIB load command with the install name from the dynamic library. See Dynamic Library Identification for more on that. Undefined Symbols at Load Time When you load a Mach-O image the dynamic linker is responsible for finding all the libraries it depends on, loading them, and connecting your imports to their exports. In the typical case the undefined entry in your symbol table records the symbol name and the library that exports the symbol. This allows the dynamic linker to quickly and unambiguously find the correct symbol. However, if the entry is marked as dynamic lookup [1], the dynamic linker will search all loaded images for the symbol and connect your library to the first one it finds. If the dynamic linker is unable to find a symbol, its default behaviour is to fail the load of the Mach-O image. This changes if the symbol is a weak reference. In that case, the dynamic linking continues to load the image but sets the address of the symbol to NULL. See Weak vs Weak vs Weak, below, for more about this. [1] In this case nm shows the library name as dynamically looked up. Weak vs Weak vs Weak Mach-O supports two different types of weak symbols: Weak references (aka weak imports) Weak definitions IMPORTANT If you use the term weak without qualification, the meaning depends on your audience. App developers tend to assume that you mean a weak reference whereas folks with a C++ background tend to assume that you mean a weak definition. It’s best to be specific. Weak References Weak references support the availability mechanism on Apple platforms. Most developers build their apps with the latest SDK and specify a deployment target, that is, the oldest OS version on which their app runs. Within the SDK, each declaration is annotated with the OS version that introduced that symbol [1]. If the app uses a symbol introduced later than its deployment target, the compiler flags that import as a weak reference. The app is then responsible for not using the symbol if it’s run on an OS release where it’s not available. For example, consider this snippet: #include <xpc/xpc.h> void testWeakReference(void) { printf("%p\n", xpc_listener_set_peer_code_signing_requirement); } The xpc_listener_set_peer_code_signing_requirement function is declared like so: API_AVAILABLE(macos(14.4)) … int xpc_listener_set_peer_code_signing_requirement(…); The API_AVAILABLE macro indicates that the symbol was introduced in macOS 14.4. If you build this code with the deployment target set to macOS 13, the symbol is marked as a weak reference: % nm -m Products/Debug/TestWeakRefC … (undefined) weak external _xpc_listener_set_peer_code_signing_requirement (from libSystem) If you run the above program on macOS 13, it’ll print NULL (actually 0x0). Without support for weak references, the dynamic linker on macOS 13 would fail to load the program because the _xpc_listener_set_peer_code_signing_requirement symbol is unavailable. [1] In practice most of the SDK’s declarations don’t have availability annotations because they were introduced before the minimum deployment target supported by that SDK. Weak definitions Weak references are about imports. Weak definitions are about exports. A weak definition allows you to export a symbol from multiple images. The dynamic linker coalesces these symbol definitions. Specifically: The first time it loads a library with a given weak definition, the dynamic linker makes it the primary. It registers that definition such that all references to the symbol resolve to it. This registration occurs in a namespace dedicated to weak definitions. That namespace is flat. Any subsequent definitions of that symbol are ignored. Weak definitions are weird, but they’re necessary to support C++’s One Definition Rule in a dynamically linked environment. IMPORTANT Weak definitions are not just weird, but also inefficient. Avoid them where you can. To flush out any unexpected weak definitions, pass the -warn_weak_exports option to the static linker. The easiest way to create a weak definition is with the weak attribute: __attribute__((weak)) void testWeakDefinition(void) { } IMPORTANT The C++ compiler can generate weak definitions without weak ever appearing in your code. This shows up in nm like so: % nm -m Products/Debug/TestWeakDefC … 0000000100003f40 (__TEXT,__text) weak external _testWeakDefinition … The output is quite subtle. A symbol flagged as weak external is either a weak reference or a weak definition depending on whether it’s undefined or not. For clarity, use dyld_info instead: % dyld_info -imports -exports Products/Debug/TestWeakRefC Products/Debug/TestWeakDefC [arm64]: … -imports: … 0x0001 _xpc_listener_set_peer_code_signing_requirement [weak-import] (from libSystem) % dyld_info -imports -exports Products/Debug/TestWeakDefC Products/Debug/TestWeakDefC [arm64]: -exports: offset symbol … 0x00003F40 _testWeakDefinition [weak-def] … … Here, weak-import indicates a weak reference and weak-def a weak definition. Weak Library There’s one final confusing use of the term weak, that is, weak libraries. A Mach-O image includes a list of imported libraries and a list of symbols along with the libraries they’re imported from. If an image references a library that’s not present, the dynamic linker will fail to load the library even if all the symbols it references in that library are weak references. To get around this you need to mark the library itself as weak. If you’re using Xcode it will often do this for your automatically. If it doesn’t, mark the library as optional in the Link Binary with Libraries build phase. Use otool to see whether a library is required or optional. For example, this shows an optional library: % otool -L Products/Debug/TestWeakRefC Products/Debug/TestWeakRefC: /usr/lib/libEndpointSecurity.dylib (… 511.60.5, weak) … In the non-optional case, there’s no weak indicator: % otool -L Products/Debug/TestWeakRefC Products/Debug/TestWeakRefC: /usr/lib/libEndpointSecurity.dylib (… 511.60.5) … Debug Symbols or Why the DWARF still stabs. (-: Historically, all debug information was stored in symbol table entries, using a format knows as stabs. This format is now obsolete, having been largely replaced by DWARF. However, stabs symbols are still used for some specific roles. Note See <mach-o/stab.h> and the stab man page for more about stabs on Apple platforms. See stabs and DWARF for general information about these formats. In DWARF, debug symbols aren’t stored in the symbol table. Rather, debug information is stored in various __DWARF sections. For example: % otool -l Intermediates.noindex/TestSymTab.build/Debug/TestSymTab.build/Objects-normal/arm64/TestCore.o | grep __DWARF -B 1 sectname __debug_abbrev segname __DWARF … The compiler inserts this debug information into the Mach-O object file that it creates. Eventually this Mach-O object file is linked into a Mach-O image. At that point one of two things happens, depending on the Debug Information Format build setting. During day-to-day development, set Debug Information Format to DWARF. When the linker creates a Mach-O image from a bunch of Mach-O object files, it doesn’t do anything with the DWARF information in those objects. Rather, it records references to the source objects files into the final image. This is super quick. When you debug that Mach-O image, the debugger finds those references and uses them to locate the DWARF information in the original Mach-O object files. Each reference is stored in a stabs OSO symbol table entry. To see them, run nm with the -a option: % nm -a Products/Debug/TestSymTab … 0000000000000000 - 00 0001 OSO …/Intermediates.noindex/TestSymTab.build/Debug/TestSymTab.build/Objects-normal/arm64/TestCore.o 0000000000000000 - 00 0001 OSO …/Intermediates.noindex/TestSymTab.build/Debug/TestSymTab.build/Objects-normal/arm64/main.o … Given the above, the debugger knows to look for DWARF information in TestCore.o and main.o. And notably, the executable does not contain any DWARF sections: % otool -l Products/Debug/TestSymTab | grep __DWARF -B 1 % When you build your app for distribution, set Debug Information Format to DWARF with dSYM File. The executable now contains no DWARF information: % otool -l Products/Release/TestSymTab | grep __DWARF -B 1 % Xcode runs dsymutil tool to collect the DWARF information, organise it, and export a .dSYM file. This is actually a document package, within which is a Mach-O dSYM companion file: % find Products/Release/TestSymTab.dSYM Products/Release/TestSymTab.dSYM Products/Release/TestSymTab.dSYM/Contents … Products/Release/TestSymTab.dSYM/Contents/Resources/DWARF Products/Release/TestSymTab.dSYM/Contents/Resources/DWARF/TestSymTab … % file Products/Release/TestSymTab.dSYM/Contents/Resources/DWARF/TestSymTab Products/Release/TestSymTab.dSYM/Contents/Resources/DWARF/TestSymTab: Mach-O 64-bit dSYM companion file arm64 That file contains a copy of the the DWARF information from all the original Mach-O object files, optimised for use by the debugger: % otool -l Products/Release/TestSymTab.dSYM/Contents/Resources/DWARF/TestSymTab | grep __DWARF -B 1 … sectname __debug_line segname __DWARF … Raw Symbol Information As described above, each Mach-O file has a symbol table that’s an array of symbol table entries. The structure of each entry is defined by the declarations in <mach-o/nlist.h> [1]. While there is an nlist man page, the best documentation for this format is the the comments in the header itself. Note The terms nlist stands for name list and dates back to truly ancient versions of Unix. Each entry is represented by an nlist_64 structure (nlist for 32-bit Mach-O files) with five fields: n_strx ‘points’ to the string for this entry. n_type encodes the entry type. This is actually split up into four subfields, as discussed below. n_sect is the section number for this entry. n_desc is additional information. n_value is the address of the symbol. The four fields within n_type are N_STAB (3 bits), N_PEXT (1 bit), N_TYPE (3 bits), and N_EXT (1 bit). To see these raw values, run nm with the -x option: % nm -a -x Products/Debug/TestSymTab … 0000000000000000 01 00 0300 00000036 _getpid 0000000100003f44 24 01 0000 00000016 _main 0000000100003f44 0f 01 0000 00000016 _main … This prints a column for n_value, n_type, n_sect, n_desc, and n_strx. The last column is the string you get when you follow the ‘pointer’ in n_strx. The mechanism used to encode all the necessary info into these fields is both complex and arcane. For the details, see the comments in <mach-o/nlist.h> and <mach-o/stab.h>. However, just to give you a taste: The entry for getpid has an n_type field with just the N_EXT flag set, indicating that this is an external symbol. The n_sect field is 0, indicating a text symbol. And n_desc is 0x0300, with the top byte indicating that the symbol is imported from the third dynamic library. The first entry for _main has an n_type field set to N_FUN, indicating a stabs function symbol. The n_desc field is the line number, that is, line 22. The second entry for _main has an n_type field with N_TYPE set to N_SECT and the N_EXT flag set, indicating a symbol exported from a section. In this case the section number is 1, that is, the text section. [1] There is also an <nlist.h> header that defines an API that returns the symbol table. The difference between <nlist.h> and <mach-o/nlist.h> is that the former defines an API whereas the latter defines the Mach-O on-disk format. Don’t include both; that won’t end well!

Hello, We are experiencing slow launch time indicators in our performance monitoring tools(Crashlytics/DataDog/Xcode), and trying to understand what is the best approach to reduce it. Currently, cold launch takes ~900ms on iPhone 16 Pro , but ~2s on iPhone 11. Profiling app launch detected that most of the time is spend on loading the libraries. Our app is massive, we use a total of ~40 3rd parties libraries + 10 internal libraries. We enabled the "mergeable libraries" XCode new feature however the app launch is as written above. We also postponed some of the work in didFinishLaunch, which help a bit... But maybe we are trying to achieve the impossible? Could it be that large apps just can't reach the golden 500ms goal? Currently we are trying to create an "umbrella" library for all the third parties in order to force them to become part of the mergeable libraries. We would like to know if, are we on the right track?