I maintain a library that has thus far used Cocoapods to manage dependencies and also distribute an xcframework of the library. I'd now like to also distribute the same library through Swift Packages but am running into issues. I'm using the same xcframework in a local Swift Package and have added all the necessary dependencies to Package.swift, but when I attempt to add this Swift Package to a test app, the app will build correctly but fail at runtime due to a missing .framework file for a dependency I'll just call THE_DEPENDENCY: dyld[61483]: Library not loaded: @rpath/THE_DEPENDENCY.framework/THE_DEPENDENCY Referenced from: <75074516-C1CD-3251-8807-94A7502176A7> /Users/ME/Library/Developer/Xcode/DerivedData/MY_TEST_APP-bwfsfwjjnagdurdnjrhhdppgitvr/Build/Products/Debug-appletvsimulator/MY_LIBRARY.framework/MY_LIBRARY Reason: tried: '/Users/ME/Library/Developer/Xcode/DerivedData/MY_TEST_APP-bwfsfwjjnagdurdnjrhhdppgitvr/Build/Products/Debug-appletvsimulator/THE_DEPENDENCY.framework/THE_DEPENDENCY' (no such file) Indeed, there is no THE_DEPENDENCY.framework file anywhere, it is only present in a version of the test app that uses Cocoapods. As you can see, the reference to this file arises from MY_LIBRARY, and in MY_LIBRARY.xcodeproj I can see there is a reference to THE_DEPENDENCY.framework, which appears as a consequence of running pod install. Thus, it looks to me like the .framework file appears either as part of Cocoapods dependency injection, or perhaps as a consequence of how that dependency is distributed through Cocoapods. I'm forced to install pods during my build process because, as I understand it, all dependencies must be available during the archiving process to avoid compilation errors. If the dependencies must be available during archiving, but adding the dependencies via Cocoapods creates a reference to .framework files that will not be present in a Swift Package project, what is the best practice for distributing xcframework binaries to both Cocoapods and Swift Package Manager? It looks as though I'll have to build two different xcframeworks: one built with dependencies provided via pods, and the other via swift packages. Is this correct?

Xcode will build and analyze fine using the Debug build configuration but trying to use Analyze or Archive with Release configuration generates 3 errors: Undefined symbol: protocol conformance descriptor, Undefined symbol: type metadata accessor, and Undefined symbol: nominal type descriptor causing the linker to command to fail. The library is included and already linked and a previous version did not have the error so I think it's a code issue but not quite sure what it is or how to fix! The project/package can be found here: https://github.com/kudit/Device/tree/v2.1.17 (to reproduce, checkout this version and rename appending ".swiftpm" to the folder, then right-click to show package contents, open the Development folder and open the Xcode project there. It's done this way so the package can be imported and edited on iPad Swift Playgrounds)

When I Run Php Artisan Command in PhpStorm Laravel Project The below results show in the terminal. dyld[11387]: Library not loaded: @loader_path/../../../../opt/icu4c/lib/libicuio.73.dylib Referenced from: &lt;27B43AEF-470B-32CD-9521-AA834300394F&gt; /usr/local/Cellar/php/8.2.10/bin/php Reason: tried: '/usr/local/Cellar/php/8.2.10/bin/../../../../opt/icu4c/lib/libicuio.73.dylib' (no such file), '/usr/local/lib/libicuio.73.dylib' (no such file), '/usr/lib/libicuio.73.dylib' (no such file, not in dyld cache) zsh: abort php artisan

Hello, I have a problem with an iOS app that is deployed via the MDM system Intune. The app closes immediately after starting. The APP works without distribution via the MDM. Devices with iOS 17 also work. I am attaching a crash report. (txt is ips) Unfortunately I have no idea how to solve the problem because it only occurs via the MDM and therefore I cannot debug it. The problem occurs in production environment. Please help me with the solution. Insight Mobile-2024-06-24-144828.txt Best regards Moritz

I'm working on a macOS app. Due to security requirement, I add the following line in XCode other linker flags: -Wl,-sectcreate,__RESTRICT,__restrict,/dev/null But after testing, we found that app crashed at launch if system integrity protection disabled. Here is the report: System Integrity Protection: disabled Crashed Thread: 0 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace DYLD, Code 1 Library missing Library not loaded: @rpath/MyLib.framework/Versions/A/MyLib Referenced from: <845E83E4-9526-36F0-8A2D-ADD407697F4D> /Applications/MyApp/MyApp.app/Contents/MacOS/MyApp Reason: tried: '/System/Library/Frameworks/MyLib.framework/Versions/A/MyLib' (no such file, not in dyld cache), (security policy does not allow @ path expansion) (terminated at launch; ignore backtrace) Thread 0 Crashed: 0 dyld 0x185f3a55c __abort_with_payload + 8 1 dyld 0x185f46b10 abort_with_payload_wrapper_internal + 104 2 dyld 0x185f46b44 abort_with_payload + 16 3 dyld 0x185ecd584 dyld4::halt(char const*, dyld4::StructuredError const*) + 304 4 dyld 0x185eca254 dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3884 5 dyld 0x185ec8edc start + 1844 Looks like dyld can't load rpath if restrict segment exist & SIP disabled. Is there a way to fix it? The framework & dylib files needs to be in the bundle to avoid other app using them, so point to /usr/lib is not an option. Thanks.

dyld[766]: Library not loaded: @rpath/lib/libswiftCoreGraphics.dylib Referenced from: /private/var/containers/Bundle/Application/94ECCB38-EB17-4A37-8D38-5D50018D135C/Coloring Book.app/Coloring Book Reason: tried: '/usr/lib/system/introspection/libswiftCoreGraphics.dylib' (no such file, not in dyld cache), '/usr/lib/swift/lib/libswiftCoreGraphics.dylib' (no such file, not in dyld cache), '/private/preboot/Cryptexes/OS/usr/lib/swift/lib/libswiftCoreGraphics.dylib' (no such file), '/private/var/containers/Bundle/Application/94ECCB38-EB17-4A37-8D38-5D50018D135C/Coloring Book.app/Frameworks/lib/libswiftCoreGraphics.dylib' (no such file), '/private/var/containers/Bundle/Application/94ECCB38-EB17-4A37-8D38-5D50018D135C/Coloring Book.app/Frameworks/lib/libswiftCoreGraphics.dylib' (no such file), '/usr/lib/swift/lib/libswiftCoreGraphics.dylib' (no such file, not in dyld cache), '/private/preboot/Cryptexes/OS/usr/lib/swift/lib/libswiftCoreGraphics.dylib' (no such file), '/private/var/containers/Bundle/Application/94ECCB38-EB17-4A37-8D38-5D50018D135C/Coloring Book.app/Frameworks/lib/libswiftCoreGraphics.dylib' (no such file), '/private/var/containers/Bundle/Application/94ECCB38-EB17-4A37-8D38-5D50018D135C/Coloring Book.app/Frameworks/lib/libswiftCoreGraphics.dylib' (no such file)

Hi there, My app detects connected BlackMagic devices on a user's machine and this is done using the DeckLink SDK which first tries to load /Library/Frameworks/DeckLinkAPI.framework using CFBundleCreate. I have not been able to create a notarized app which successfully detects the devices. Either the DeckLinkAPI works or the app starts up without showing "the developer cannot be verified" on my test computer but never both. This is what I've tried so far: signed app: DeckLinkAPI available hardened runtime: DeckLinkAPI not available hardened runtime + com.apple.security.cs.disable-library-validation: DeckLinkAPI available, notarization succeeds yet the "the developer cannot be verified" I've also tried to use weak linking to DeckLinkAPI.framework instead of including the SDK's CFBundleCreate code but that made no difference: I still needed the com.apple.security.cs.disable-library-validation entitlement for that to work which caused "the developer cannot be verified". DeckLinkAPI.framework is notarized: > codesign --test-requirement="=notarized" --verify --verbose /Library/Frameworks/DeckLinkAPI.framework /Library/Frameworks/DeckLinkAPI.framework: valid on disk /Library/Frameworks/DeckLinkAPI.framework: satisfies its Designated Requirement /Library/Frameworks/DeckLinkAPI.framework: explicit requirement satisfied Is there any way to successfully notarize an app to use the DeckLink SDK or any other thirdparty notarized framework which is distributed seperately?

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

The following program demonstrates the issue. It prints: y = 2.000000 CGRectMake symbol not found What would cause the symbol not to be found when using the dlopen/dlsym functions? #import <CoreGraphics/CoreGraphics.h> #import <dlfcn.h> int main(int argc, const char * argv[]) { CGRect rect = CGRectMake(1.0, 2.0, 3.0, 4.0); printf("y = %f\n", rect.origin.y); void * handle = dlopen("/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics", RTLD_LAZY); if (handle == NULL) { printf("handle == NULL\n"); } else if (dlsym(handle, "CGRectMake") == NULL) { printf("CGRectMake symbol not found\n"); } return 0; } I am observing this issue with other symbols as well. What is special about them?

Hello, I get a lot of crashlogs from MetricKit watchdog on iOS 17.5.1 all related to dyld. Does anybody has the same issue or any idea what could be the problem? Attached is the watchdog log. wathchdog exhausted real (wall clock) time allowance of 30.00 seconds ProcessVisibility: Background ProcessState: Running WatchdogEvent: process-launch. crash in dyld process Following error is shown: 0 Thread 0 1 dyld objc::findhash(dyld3::OverflowSafeArray<objc::bstuff, 4294967295ull>&, unsigned int*, unsigned long long*, unsigned int*, unsigned int, dyld3::OverflowSafeArray<objc::PerfectHash::key, 4294967295ull>&) + 584 2 dyld objc::PerfectHash::make_perfect(dyld3::OverflowSafeArray<objc::PerfectHash::key, 4294967295ull>&, objc::PerfectHash&) + 124 3 dyld objc::PerfectHash::make_perfect(dyld3::OverflowSafeArray<char const*, 4294967295ull> const&, objc::PerfectHash&) + 152 4 dyld dyld4::PrebuiltObjC::generateHashTables(dyld4::RuntimeState&) + 128 5 dyld dyld4::PrebuiltObjC::make(Diagnostics&, dyld4::RuntimeState&) + 2968 6 dyld dyld4::PrebuiltLoaderSet::makeLaunchSet(Diagnostics&, dyld4::RuntimeState&, dyld4::MissingPaths const&) + 468 7 dyld dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 2920 8 dyld start + 1724 MetricKitLog.txt diagnostic.json

Looking for anyone that has some experience in getting Xcode to work with external compiler/linkers in what is tantamount to a foreign tool chain to build non-apple platform executables. For example, I want to ultimately use Xcode to edit, build, and push bare metal firmware (read "no operating system at external device"). Think of it as in how to use Xcode to develop the firmware in the processor in the ThunderBolt 4 cable (TPS65994AD) which runs a variant of the ARM Cortex-M machine code. Suppose I don't want to use TI's "Code Composer Studio (CCS)" but instead want to use Xcode which might drive some part of Code Composer Studio. Xcode supports external / foreign tool chains (or did) but the question is "have you done it successfully for any foreign platform?" and if so what was your approach? I'm trying to not waste a bunch of time with horrendous make file scripting only to find out that I did not have to do it or it headed down the wrong directions. I have a hard time believing that someone hasn't done this before for something even more monolithic like Arduino.

Hello, I get a lot of crashlogs from MetricKit watchdog on iOS 17.5.1 all related to dyld. Does anybody has the same issue or any idea what could be the problem? Attached is the Crashlog. Following error is shown: 0 Thread 0 1 dyld objc::findhash(dyld3::OverflowSafeArray<objc::bstuff, 4294967295ull>&, unsigned int*, unsigned long long*, unsigned int*, unsigned int, dyld3::OverflowSafeArray<objc::PerfectHash::key, 4294967295ull>&) + 584 2 dyld objc::PerfectHash::make_perfect(dyld3::OverflowSafeArray<objc::PerfectHash::key, 4294967295ull>&, objc::PerfectHash&) + 124 3 dyld objc::PerfectHash::make_perfect(dyld3::OverflowSafeArray<char const*, 4294967295ull> const&, objc::PerfectHash&) + 152 4 dyld dyld4::PrebuiltObjC::generateHashTables(dyld4::RuntimeState&) + 128 5 dyld dyld4::PrebuiltObjC::make(Diagnostics&, dyld4::RuntimeState&) + 2968 6 dyld dyld4::PrebuiltLoaderSet::makeLaunchSet(Diagnostics&, dyld4::RuntimeState&, dyld4::MissingPaths const&) + 468 7 dyld dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 2920 8 dyld start + 1724

Hello, I get a lot of crashlogs from MetricKit watchdog on iOS 17.5.1 all related to dyld. Does anybody has the same issue or any idea what could be the problem? Attached is the Crashlog. wathchdog exhausted real (wall clock) time allowance of 30.00 seconds ProcessVisibility: Background ProcessState: Running WatchdogEvent: process-launch. crash in dyld process Following error is shown: 0 Thread 0 1 dyld objc::findhash(dyld3::OverflowSafeArray<objc::bstuff, 4294967295ull>&, unsigned int*, unsigned long long*, unsigned int*, unsigned int, dyld3::OverflowSafeArray<objc::PerfectHash::key, 4294967295ull>&) + 584 2 dyld objc::PerfectHash::make_perfect(dyld3::OverflowSafeArray<objc::PerfectHash::key, 4294967295ull>&, objc::PerfectHash&) + 124 3 dyld objc::PerfectHash::make_perfect(dyld3::OverflowSafeArray<char const*, 4294967295ull> const&, objc::PerfectHash&) + 152 4 dyld dyld4::PrebuiltObjC::generateHashTables(dyld4::RuntimeState&) + 128 5 dyld dyld4::PrebuiltObjC::make(Diagnostics&, dyld4::RuntimeState&) + 2968 6 dyld dyld4::PrebuiltLoaderSet::makeLaunchSet(Diagnostics&, dyld4::RuntimeState&, dyld4::MissingPaths const&) + 468 7 dyld dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 2920 8 dyld start + 1724 MetricKitLog.txt

I have a third party library added to my project as ThirdParty.framework, but it only supports real device. I want to make my project still build for simulators but exclude this library and any references of importing it. I tried a few things, for example in the target's build phase "Link Binary With Libraries" set this framework as "Optional", and in the code I have: #if !targetEnvironment(simulator) import ThirdParty class SomeClass: ProtocolFromThirdParty { // ... } #endif Also some view that has reference to this class: import SwiftUI #if targetEnvironment(simulator) struct TestViewSimulator: View { var body: some View { Text("See this view on real device") } } #else struct TestView: View { @StateObject var example = SomeClass() var body: some View { // ... } } #endif But still when I build for simulator, it still gives error for the linking issue: Building for 'iOS-simulator', but linking in object file (/<Path>/ThirdParty.framework/ThirdPartySDK[arm64][2](someobject.o)) built for 'iOS' Building to a real device works as expected. Any suggestions I could make it build on simulators? (I'd like to isolate this screen only for real device and not impacting other parts of the app)

I used to have a static library, I turned it into a dynamic library, which was more difficult than I expected. I already had a small project, containing a command line tool which loads a dynamic library. This was created direct from Xcode 15.3's macOS app and dynamic library templates. This is how I configured the Dynamic Library Install Name Base to @rpath. Note that there is nothing in the Dynamic Library Install Name target setting, but it resolves to @rpath/libCLI_library.dylib. If I click on it once, I can see the value I click on it again to see how this value is generated The expression it is generated from is $(LD_DYLIB_INSTALL_NAME_$(LLVM_TARGET_TRIPLE_VENDOR):default=$(EXECUTABLE_PATH)) Using a Run Script phase I can see the environment variables, which include LLVM_TARGET_TRIPLE_VENDOR = “apple”, and LD_DYLIB_INSTALL_NAME_apple = “@rpath/libCLI_.dylib” If I look at the environment variables in my other dylib project, which started life as a static library, although LLVM_TARGET_TRIPLE_VENDOR is set to "apple", there is no LD_DYLIB_INSTALL_NAME_apple variable at all, so even if I paste the expression above into the LD_DYLIB_INSTALL_NAME setting, it does me no good, because it evaluates to EXECUTABLE_PATH, which is libXXX.dylib, but I'd like @rpath/libXXX.dylib. So my question are, where does LD_DYLIB_INSTALL_NAME_apple come from? where does the magic invisible expression for Dynamic Library Install Name come from? the quick help for Dynamic Library Install Name mentions "if this option is not specified, the -o path will be used" - what build setting is that?

I've been given an Xcode project which produces a command line tool which links to a dylib. I have the dylib, but not its source code. I change the signing option for the command line tool target so it is signed automatically by my personal team. On an attempt to run the tool, it fails to load the dylib, because the dylib is signed with a different certificate. I manually codesign the dylib with the same certificate I am using for the command line app. Now, I can build the app, but not run it. If I try to do so, I see four dialogs telling me “libXXX.dylib” can’t be opened because Apple cannot check it for malicious software, then the console tells me "'/path/to/libXXX.dylib' not valid for use in process: library load disallowed by system policy)" I found an old document about Gatekeeper (https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html) which suggests that Gatekeeper just won't let me do this - I can't just put the dylib next to the executable, although the dynamic linker finds the dylib, Gatekeeper doesn't like it because the dylib isn't inside the app bundle (there is none), and isn't in one of the well-known places. I dealt with this by making a do-nothing app which I can sign with my personal certificate. Then I replace the signature on the dylib (and its dependent dylibs) with my own. I add the command line tool and all its dylib dependencies to the do-nothing app, then add those files into the Copy Bundle Resources phase of the do-nothing app. Now, the command line tool and its dylibs all live in do-nothing.app/Contents/Resources, and I can run the tool from there without Gatekeeper complaining. Is there an easier way (aside from asking my supplier for static libraries)? And if this is the only way, is Contents/Resources the right place to put command line tools and the dylibs they link to?

I'm trying to compile a little project in C with the following structure: Project | |-&gt;Headers |-&gt;library.h | |-&gt;src |-&gt;main.c |-&gt;library.c I've checked all my files, my configurations files and I'm getting the same error everytime, someone could please help me? :( Undefined symbols for architecture arm64: "_getfavoritenumber", referenced from: _main in main-99c109.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

I have an iOS SwiftUI app which uses some extensions like NotificationServiceExtension, NotificationContentExtension, WidgetExtension etc. I noticed that each extension uses its own process and has its own bundle with the .appex extension... and is packaged within the app bundle, with .app extension. In my case, most of my logic is in C++ and when the app starts up, it needs to 'startup' the C++ layer. Now, in WidgetExtension, if it's going to read data from disk and update its interface, I need to initialise my C++ layer first. The same can be said for NotificationServiceExtension. This is leading me to include all my C++ artefacts into the extension target as well. Here's my problem: If the size of my app (containing all my C++ artefacts) is 10MB and I'm using 20 extensions (say), the final size of the shipped app bundle is 10MB + (20 * 10MB) = 210MB, since extension bundle (.appex) is packaged within the app bundle (.app). Since the app and the extensions are using the same C++ artefacts, I was hoping to have one binary in the bundle. The app and its extensions will point to this binary. When the app is launched, the app entry point (struct conforming to App protocol) is invoked, in case of widget, the widget entry point (WidgetBundle) is invoked and so on for each extension. This will reduce the final size of the app bundle. Is it possible to have one binary and the app target, all extension targets would use this binary for there functioning?

Xcode 15 introduced official support for static frameworks. docs here This is presumably because there's quite a bit over overlap with the mergeable libraries feature. Static frameworks potentially give developers a nice option for bundling resources with a static library. This was previously only really viable if you explicitly packaged up a .bundle with your .a (static library) which could be cumbersome for both the creator and consumer of a library. Or you explicitly copied your framework resources into your main app binary when building your app. The release notes for Xcode 15 state: Embedding a static framework using a Copy Files build phase now removes the static archive from the framework when it is embedded in the target bundle. When inspecting the app target on disk this appears to be the case. In fact the behaviour is the same as with a mergable in release mode whereby a "stub" binary exists with no symbols. The release notes also state: The COPY_RESOURCES_FROM_STATIC_FRAMEWORKS build setting, previously used in the legacy build system to extract and copy the resources from a static framework to the target bundle, no longer has any effect with the new build system as the entire framework is copied instead This also appears to be the case when inspecting the files on disk as the frameworks appear to be present in the main app with their resources. So far so good. The issue arises when trying to access the bundle associated with this framework. The documentation doesn't mention any special access requirements to it's assumed that standard bundle access APIs should work. Using a class let bundle = Bundle(for: InfoCoreMain.self) This returns the main application bundle and therefore fails to find the correct asset. This can be rationalised by the fact that the InfoCoreMain class does now actually exist within the main app target binary due to being statically linked. It's worth noting however, that mergable libraries in release mode do seem to work in this way and can resolve the bundle fine*. Using an explicit bundle identifier let bundle = Bundle(identifier: "***.***.InfoCore") Using an explicit bundle identifier returns nil even though we can see the framework on disk. Using a path Using a path to access the framework also doesn't work. if let bundlePath = Bundle.main.path(forResource: "InfoCore", ofType: "framework") { let bundle = Bundle(path: bundlePath) // Now you can access resources in the framework bundle } else { // Framework bundle not found } All of the above is the same behaviour for release and debug builds. I have tried this on Xcode 15.2 and 15.3 *Mergeable libraries do seem to have issues in debug mode. See this forum post. https://forums.developer.apple.com/forums/thread/749818

Assuming I have a static library where all global symbols need to be re-exported by the target executable. How do I extract these symbols into a file to be used with ld's -exported_symbols_list and Xcode's EXPORTED_SYMBOLS_FILE? I was thinking about nm -gUjo … + sed but maybe there is abetter way?