After the Update of Latest Command Line Tools 16.3 I am facing issue to compile C++ programs. Like it is giving some kind of library error in the MACOSX15.sdk file and this is the error. In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/mach/machine/_structs.h:35, from /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/arm/_mcontext.h:36, from /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/machine/_mcontext.h:34, from /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/sys/signal.h:146, from /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/sys/wait.h:109, from /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/_stdlib.h:70, from /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/stdlib.h:58, from /opt/homebrew/Cellar/gcc/14.2.0_1/include/c++/14/cstdlib:79, from /opt/homebrew/Cellar/gcc/14.2.0_1/include/c++/14/stdlib.h:36, from /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/assert.h:44, from /opt/homebrew/Cellar/gcc/14.2.0_1/include/c++/14/cassert:44, from /opt/homebrew/Cellar/gcc/14.2.0_1/include/c++/14/aarch64-apple-darwin24/bits/stdc++.h:33, from 1.cpp:1: /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/mach/arm/_structs.h:627:35: error: expected primary-expression before 'unsigned' 627 | } __attribute__((aligned(_Alignof(unsigned int)))); | ^~~~~~~~ /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/mach/arm/_structs.h:627:26: error: '_Alignof' was not declared in this scope 627 | } __attribute__((aligned(_Alignof(unsigned int)))); | ^~~~~~~~ /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/mach/arm/_structs.h:633:35: error: expected primary-expression before 'unsigned' 633 | } __attribute__((aligned(_Alignof(unsigned int)))); | ^~~~~~~~ /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/mach/arm/_structs.h:633:26: error: '_Alignof' was not declared in this scope 633 | } __attribute__((aligned(_Alignof(unsigned int)))); | ^~~~~~~~ /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/mach/arm/_structs.h:639:35: error: expected primary-expression before 'unsigned' 639 | } __attribute__((aligned(_Alignof(unsigned int)))); | ^~~~~~~~ /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/mach/arm/_structs.h:639:26: error: '_Alignof' was not declared in this scope 639 | } __attribute__((aligned(_Alignof(unsigned int)))); | ^~~~~~~~ /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/mach/arm/_structs.h:645:35: error: expected primary-expression before 'unsigned' 645 | } __attribute__((aligned(_Alignof(unsigned int)))); | ^~~~~~~~ /Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk/usr/include/mach/arm/_structs.h:645:26: error: '_Alignof' was not declared in this scope 645 | } __attribute__((aligned(_Alignof(unsigned int)))); But after downgrading the version to 16.2 it works fine. I can't understand that it's their any issue with Command Line Tools 16.3??

Calling dlopen then dlclose causes an increase in the amount of memory used by the program. If I create a loop that calls dlopen / dlclose repeatedly on the same dynamic library, memory usage increases continuously. Is this a bug, or am I using dlopen / dlclose incorrectly? I can reproduce this by modifying the sample code in the Apple Developer docs Creating Dynamic Libraries. If I modify Runtime.c, changing the line void *lib_handle = dlopen(lib_name, RTLD_NOW); to add the infinite loop, as below: void *lib_handle = dlopen(lib_name, RTLD_NOW); for (int ii = 0; ; ++ii) { printf("loop %i\n", ii); int close_err = dlclose(lib_handle); printf("close error: %i\n", close_err); printf("dlopen(%s, RTLD_NOW)\n", lib_name); lib_handle = dlopen(lib_name, RTLD_NOW); } then opening and closing the dynamic library will succeed, but memory usage (as reported by top) will rapidly increase. I'm running on x86_64 macOS 13.6.6. Full code for the modified Runtime.c is attached, the rest of the code is available in the Apple Developer docs. Any suggestions? Many thanks, Chris Runtime.c

Just recently, any pkg file that I create with pkgbuild will install the Payload's application as a zero-byte file in the /Applications directory. This has been working for years without issue for me. Here are the commands I am using with company specific items replaced: pkgbuild --analyze --root MyApplicationRootDirectory standalone.plist plutil -replace BundleIsRelocatable -bool NO standalone.plist pkgbuild --identifier MyIdentifier --version 1.0 --install-location /Applications --root MyApplicationRootDirectory --component-plist standalone.plist --sign 'Developer ID Installer: MyCompany (MySignId)' --timestamp installer.pkg Any ideas on what could be causing the issue? I have verified the following: The application being added to the pkg is both signed and notarized using the correct Developer ID Application certificate. The resultant pkg file is both signed and notarized using the Developer ID Installer certificate. Verified the pkg contents using "pkgutil --expand" to dump the contents. Verified the pkg's Payload contents by extracting the data using "cat Payload | gunzip | cpio -1". This results in an application file that is a binary match for file added in the "pkgbuild --root" argument. My application is the only file within the directory passed to the "pkgbuild --root" argument. There are no warnings in the System Settings / Privacy & Security Panel when running the package installer. I have a valid Mac Developer account. I am building the application and the pkg file on the same computer. Thank you for any insight.

I have two feedbacks now where I’ve been requested additional info, and provided it, but the feedback still has an “unread” dot, and is still in the “Requests” folder. I’ve asked multiple times to clear this status in one of those feedbacks (FB14888965), but got no response. Not the end of the world as long as the engineers are notified, but iirc the dot would disappear as soon as I replied.

I was just having a look at some crash reports downloaded by Xcode, and I noticed the same wrong pattern I already mentioned here: the crash reports indicate that method A calls method B, which is impossible. In the first crash report below, method MainViewController.showSettings seems to be called by ConfirmMoveViewController.openSourceInFinder, which is impossible. ConfirmMoveViewController.openSourceInFinder is a context menu action in a modal window, and MainViewController.showSettings is in a completely different window and the two methods have no relation whatsoever. In the second crash report below, MainViewController.setSortMode is triggered by the press of a button (and nothing else) but seems to be called by OtherViewController.copy that can be triggered by a context menu (or keyboard shortcut). The two methods have no relation whatsoever. The rest of the stack trace confirm that it's indeed the button that was pressed. This seems to me like a quite serious bug in how macOS creates crash reports. 1.crash 2.crash

Hi, Problem When playing videos on the Developer app on the Mac, there is no full screen button for the video. So it is not possible to play the video in full screen. Note I am not referring to the app going into full screen, the issue is with there is no option to play the video in full screen. Environment OS: macOS 26.2 (25C56) Developer app: Version 10.8.3 (1083.3.1) Feedback FB21343934 Recording Question Are others also facing this issue? Is there a workaround? Suggestion This seems to be recurring problem that seems get broken with app / OS releases. Please write some UI tests to ensure the full screen button is present. Would really appreciate if this gets fixed.

I used to develop iPhone apps about a decade ago and am now back at it with an iPhone and companion Apple Watch app. Why does it suck so bad? I a must be doing something wrong, but what I am doing is out of the box. The majority of the time when I go to build on the watch I get: Previous preparation error: A connection to this device could not be established.; Timed out while attempting to establish tunnel using negotiated network parameters. Which I then first try to force quit the app on the watch and if that does not work, reboot the watch (which is pretty ridiculous). I tried Gemini and it gave me the following explanation: This is arguably the single most frustrating error in the entire watchOS development ecosystem. As an expert, I can tell you that you are not doing anything wrong; you are fighting a fragile architecture. Here is the technical breakdown of why this happens and a workflow to mitigate it without constant reboots. The Technical "Why" This error message reveals that the issue lies in the CoreDevice (and formerly usbmuxd) infrastructure, specifically in the secure transport layer. The "Tunnel" Failure: Xcode attempts to establish a secure, encrypted tunnel (DTXConnection) to the Apple Watch to push the debugger and the app binary. Unlike the iPhone, which can sustain a high-bandwidth connection easily, the Watch aggressively manages its radios (Bluetooth vs. WiFi vs. AWDL) to save battery. The "Handshake" Timeout: If the Watch is on Bluetooth (Low Energy) when Xcode initiates the tunnel, the bandwidth is insufficient. The system tries to escalate the connection to WiFi (or Apple Wireless Direct Link). If this negotiation takes even a few milliseconds too long—due to 2.4GHz interference, router mDNS configuration, or the Watch CPU being throttled—the handshake times out. The "Previous Preparation Error": This is the insidious part. Once the handshake fails once, Xcode’s device service caches that failure state for the device UUID. It marks the device as "unreachable" to prevent the IDE from hanging indefinitely on subsequent tries. Why you see it constantly: You aren't actually triggering a new connection attempt; you are hitting the cached "failed" state immediately. Unfortunately, the solutions it gives me are: The "Wired Proxy" Method (Most Reliable) This is the gold standard for watchOS debugging. Do not rely on "Connect via Network" for the Watch directly if you can avoid it. Disable WiFi on your Mac (temporarily) or ensure the Mac and iPhone are on the exact same SSID. Plug your iPhone into the Mac via USB. Ensure the Watch is paired to that iPhone. Result: Xcode will tunnel the instructions through the USB connection to the Phone, and the Phone acts as a high-bandwidth proxy to the Watch. This eliminates the "Mac-to-Watch" WiFi negotiation failure point. Do you hit this regularly? What do you do to make for a smooth development and deployment process? Or is it really this fragile? Thanks for any help! Bryan

Hello, I'm checking to see if anyone else is experiencing an issue downloading the latest beta simulator. When I try to download the iOS 26 beta 5 simulator in Xcode, the download fails instantly. There is no progress, just an immediate error with no message other than the code itself: DVTDownloadableErrorDomain Code: 41. I've already restarted both Xcode and the Mac multiple times. I have also tried downloading on different networks to rule out a firewall issue.

Our app has an old codebase, originating in 2011, which started out as purely Objective-C (and a little bit of Objective-C++), but a good amount of Swift has been added over time as well. Lots of Objective-C and Swift inter-op, but in general very few 3rd party libraries/frameworks. Like many other codebases of this size and age, we have a good amount of accumulated tech debt. In our case, that mostly comes in the form of using old/deprecated APIs (OpenGL primary amongst them), and also using some ‘tricks’ that allowed us to do highly customized UI popups and the like before they were officially supported by iOS, but unfortunately are still in use to this day (i.e. adding views directly to the UIWindow such that that are ‘on top’ of everything, instead of presenting a VC). Overall though, the app is very powerful and capable, and generally has a relatively low crash rate. About two months ago, we started seeing some new crashes that seemed to be totally unrelated to the code changes that were made at the time. Moreover, if a new branch with a feature or bug fix was merged in, the new crash would either disappear entirely, or move somewhere else. These were not ‘normal’ crashes either - when hooked up to the debugger in Xcode, often times the crashes would happen when calling into system library (e.g. initializing a UIColor object). Some of the steps taken to try and mitigate or eliminate these crashes include: Rolling back merges Often worked, but then most future merges would cause a new and different crash to appear Using the TSan and ASan tools to try and diagnose thread or memory issues TSan reported a couple of issues near launch that have been fixed, and there are others in some areas of the app, but they have been around a long time and don’t appear to correlate with any recent changes, nor did fixing the ones at launch (and throughout testing to try and reproduce crashes) result in elimination of the new crashes ASan does not identify any issues Modifying the code changes in a branch before merging it in In one case where the changes were limited to declaring ‘@objc static var: Bool’ in a Swift class and setting a value to it in a couple of places, simply removing the @objc from the declaration would result in the crash going away. Since the var had to be exposed to Objective-C, it was eventually moved to a pure Objective-C class that already existed and is a singleton (not ideal, but it’s been around a long time and has not yet been refactored) in order to preserve the functionality and the crash was no longer reproducible Removing all 3rd party libraries or frameworks Not a long-term solution, and this mostly worked in that the crashes went away, but it also resulted in removal of long-existing features expected by our users Updating 3rd party libraries and frameworks when possible (there were some very old ones) Updating these did not have any effect on the crashes, except that the crashes moved around in the same way as when merging in a branch, and again, where the crash actually occurred was uncorrelated with the library/framework that was updated Changes to the App’s Build Settings in Xcode Set supported/valid architectures to arm64 exclusively Stripping of all architectures other than arm64 from 3rd party binaries Cleaning up of old/outdated linker flags Removal of other custom build flags that were needed at one point, but are no longer relevant Generally trying to make all the build settings in our (quite old/outdated) app match those of a newly created iOS app Code signing inject base entitlements is set to YES Removal of old/deprecated BitCode flag These changes seemed to help and the codebase was more ‘stable’ (non-crashing) for a while, but as we tried to continue development, the crashes would reappear Getting crash reports off of test devices and analyzing them based on the various documents about crash reports provided by Apple This was helpful and pointed to new things to investigate, but ultimately did not help to identify the root cause of these crashes Throughout all of the above, the crashes would come and go, very reproducibly for a given branch being merged in, but if a subsequent branch is merged in, the crash may go away, or simply move somewhere else - sometimes it would crash in our code that calls other parts of our code, and other times when calling system frameworks (like the UIColor example above). One thing that is consistent though, is that the crash would never happen anywhere near the code that was changed or added by a branch that was merged in. Additional observations when trying to figure out the cause of these crashes: Sometimes the smallest code change would result in a crash happening or not The crash reports generated on-device vary quite a bit in terms of the type and reason for the crash All crashes have an Exception Type of EXC_BAD_ACCESS, but vary between (SIGABRT) (SIGBUS) (SIGKILL) (SIGSEV) The crashing thread is often (but not always) on Thread 0 (main thread), and often the first line in the backtrace would be just ‘???’, sometimes followed by a valid memory address and file, but often times just ‘0x0 ???’ Most crash reports have an exception subtype of KERN_PROTECTION_FAILURE Many also state that the Termination Reason is ‘CODESIGNING 2 Invalid Page’ This in particular was investigated thoroughly, including looking at the Placing Content In A Bundle document but after further changes to ensure that everything is in the right place, the crashes were still observed Another odd thing in most of the crash reports is in the Binary Images section, there is a line that once again is mostly ???s or 000s - specifically ‘0x0 - 0xffffffffffffffff ??? unknown-arch <00000000000000000000000000000000> ???’ The crashes occur on different physical devices, typically the same crash for a given branch, and regardless of iOS version This includes building from different Macs. We did observe some differences between versions of Xcode (crashed similarly when built from an older version of Xcode, but not from a newer one), but we recently had all developers ensure they are running Xcode 16.4 - we also tried Xcode 26, but the crashes were still observed Overall, it seems like there is something very strange going on in terms of how the App binary is constructed such that a small code change somehow affects the binary in such a way that memory is not being accessed correctly, or is not where it is expected to be. This level of what appears to be a build-time issue that manifests in very strange run-time crashes is both confusing and difficult to diagnose. Despite the resources provided by Apple for investigation and diagnosis, we cannot seem to find a root cause for these crashes and eliminate them for good.

I just noticed that when you check the online documentation for Foundation using the delicious Objective-C flavor, some values are no more the expected ones: https://developer.apple.com/documentation/foundation/filemanager/copyitem(at:to:)?language=objc#return-value true if the item was copied successfully or the file manager’s delegate stopped the operation deliberately. Returns false if an error occurred. Considering that a BOOL used to be YES or NO for the last quarter of a century, I have the following question: [Q] What is the idea behind the disturbing changes of the Objective-C documentation?

I'm trying to download the iOS 26 restore image for my iPhone 14 Pro Max, which is my test device. However, when I attempted to install it directly via the over-the-air (OTA) update, the iPhone rebooted to the iOS 26 "Welcome" screen, but with no touch functionality—the screen was completely unresponsive. I restored the device back to iOS 18.5 and tried the OTA update again, but once more, the touch screen stopped working upon completion. Now, I am trying to download the iOS 26 restore image from the official developer page (https://developer.apple.com/download/#ios-restore-images-ipad-new) to install it manually using my Mac. However, I've run into a problem with the download links: The link for the iPhone 14 Pro Max (iOS 26) restore image actually downloads the iPhone 14 Pro (iOS 18.5) image. Conversely, the link for the iPhone 14 Pro seems to provide the correct iPhone 14 Pro Max (iOS 26) image. The issue is that when I try to restore my iPhone using this seemingly correct file, I receive an error that the firmware file is not valid or compatible. I suspect it's not being properly signed by Apple for my device during the restore process. Does anyone have the correct, official download link for the iOS 26 restore image for the iPhone 14 Pro Max? How can I fix these errors?

I've been messing around with converting my app icons to use Icon Composer. My app has multiple app icons, but I've noticed that I cant seem to set .icon files using the alternate app icon api. I believe this is due to the requirement that alternate app icons live in the Assets Catalogue but .icon files go anywhere in your project. Is there any plan to support this? Or am i missing something? I was able to successfully set a .icon file for the primary app icon.

I have one iOS device running iOS 16.7.10. When I run xcrun devicectl list devices I can't see that device at all. Is that know limitation (devicectl only work in iOS 17 and above) or is something wrong with my setup. Also is there some documention about devicectl. I can't seem to find anything about in the offical apple sites.

Hello, I am experiencing crash on TopShelf and I checked all the crashlogs, but I don't know how to interpret it. I see only addresses in the trace logs, so it's really hard to understand what's going on. Is there a way how to symbolicate frames 5 - 17? Does anybody have an idea, what can be wrong? Thanks in advance. 0 libswiftCore.dylib 0x000000019bd33a88 _assertionFailure(_:_:file:line:flags:) + 264 (AssertCommon.swift:147) 1 TopShelf 0x00000001048b998c 0x1045ac000 + 3201420 2 TopShelf 0x0000000104cc04a8 0x1045ac000 + 7423144 3 libdispatch.dylib 0x000000019ab89294 _dispatch_client_callout + 20 (object.m:576) 4 libdispatch.dylib 0x000000019ab8aae0 _dispatch_once_callout + 32 (once.c:52) 5 TopShelf 0x00000001048f4098 0x1045ac000 + 3440792 6 TopShelf 0x00000001048f4930 0x1045ac000 + 3442992 7 TopShelf 0x00000001048cc8bc 0x1045ac000 + 3279036 8 TopShelf 0x00000001045b5a61 0x1045ac000 + 39521 9 TopShelf 0x0000000104ca8841 0x1045ac000 + 7325761 10 TopShelf 0x00000001049e5cc5 0x1045ac000 + 4431045 11 TopShelf 0x0000000104cc0dfd 0x1045ac000 + 7425533 12 TopShelf 0x00000001045b4b95 0x1045ac000 + 35733 13 TopShelf 0x00000001045b4e81 0x1045ac000 + 36481 14 TopShelf 0x00000001045b50e5 0x1045ac000 + 37093 15 TopShelf 0x00000001045b5a61 0x1045ac000 + 39521 16 TopShelf 0x00000001045b54b5 0x1045ac000 + 38069 17 TopShelf 0x00000001045b50e5 0x1045ac000 + 37093 18 libswift_Concurrency.dylib 0x000000019c30aedd completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1 (Task.cpp:497)

We have universal links which takes user to various journeys in the app when user clicks on the link, however it works only when app is installed. If app is not installed link takes user to the App Store and when the user installs and opens the app, the link does not launch the intended deeplink flow. Is there any way we can pass context to app store and receive it when user opens the app? Android provides similar functionality using install referral lib. Checking if similar is possible in iOS.

Up to now I've been building my x64 binaries on Sequioa specifying a target macOS level of 13.4. That worked fine. In an attempt to debug a problem that was causing some pain I created a 13.4 x64 build environment and tried to build the code there. This code: using CacheKeyType = std::filesystem::path; using CacheValueType = std::tuple<LoadedImage, int, bool>; // <image, lastUse, currentlyLoading> using CacheType = std::unordered_map<CacheKeyType, CacheValueType>; friend class ThreadLoader; static inline constexpr int16_t MAXIMAGESINCACHE = 20; static inline constinit std::atomic_int age{ 0 }; static inline std::shared_mutex rwMutex{}; static inline CacheType imageCache{}; got me the following errors: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include/c++/v1/__hash_table:838:5: error: static_assert failed due to requirement 'integral_constant<bool, false>::value' "the specified hash does not meet the Hash requirements" static_assert(__check_hash_requirements<_Key, _Hash>::value, ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include/c++/v1/__hash_table:853:1: note: in instantiation of template class 'std::__enforce_unordered_container_requirements<std::filesystem::path, std::hash<std::filesystem::path>, std::equal_to<std::filesystem::path>>' requested here typename __enforce_unordered_container_requirements<_Key, _Hash, _Equal>::type ^ /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include/c++/v1/unordered_map:1152:30: note: while substituting explicitly-specified template arguments into function template '__diagnose_unordered_container_requirements' static_assert(sizeof(__diagnose_unordered_container_requirements<_Key, _Hash, _Pred>(0)), ""); ^ /Users/amonra/.vs/DSS/build/DeepSkyStackerKernel/DeepSkyStackerKernel_autogen/EWIEGA46WW/../../../../DeepSkyStackerKernel/imageloader.h:60:26: note: in instantiation of member function 'std::unordered_map<std::filesystem::path, std::tuple<LoadedImage, int, bool>>::~unordered_map' requested here static inline CacheType imageCache{}; ^ 2 errors generated. Which isn't "mega-helpful" :( I thought that specifying: set(CMAKE_OSX_DEPLOYMENT_TARGET 13.4 CACHE STRING "Minimum operating system version for deployment" FORCE) would have made the compilations use the same headers as for Ventura above, but it seems not? Is this to be expected?

I have created and Ios app using xojo, and run using the Xcode simulator. I want to test it on my phone and don't seed to put it on the app store as it is for personal use. I've seen pages that indicate a free apple developer option is available for a limited time but can't for the live of me get my app to actually run on my phone. I've tried both apple configurator and xcode to add my app with no luck

hey I accidentally deleted my info.plist with holds my app version and other critical things and I don't know how to get it back or how to recode it

Hi everyone, We’re testing the new iOS 26 capability, Performing Fast Account Creation with Passkeys, using the sample project provided here: Performing Fast Account Creation with Passkeys. When running the project on the iOS 26 simulator and tapping the "Sign Up" button, we encounter the following error: The operation couldn’t be completed. (com.apple.AuthenticationServices.AuthorizationError error 1010.) From the header file, this error is described as: /// ASAuthorizationError.h /// This error signals that the device is not currently set up to create passkeys. ASAuthorizationErrorDeviceNotConfiguredForPasskeyCreation AS_API_AVAILABLE(ios(19.0), macos(16.0), visionos(3.0)) = 1010, We’ve tested this on both Xcode 26 Beta 1 and Beta 2, and the error persists on the simulator in both versions. However, when testing on a physical iOS 26 device, everything works as expected, just like in the WWDC demo. Could this issue be related to missing simulator settings? Or is it a potential bug in the simulator? Any advice would be greatly appreciated. Thanks in advance!

I have an Xcode project setup as follows: 3 static libraries 1 framework target, whose Mach-O type is set to Dynamic Library main app target (iOS app) The target dependencies are as follows: In framework's build phase [Link with libraries], I have the 3 libs statically linked. In the main app's build phase [Link with libraries], I have only the framework, which is dynamically linked. As per my understanding: The libs are statically linked to the framework. So, the framework binary would contain code from all the libs. The framework is dynamically linked to the main app (iOS app in this case). So, the main app's binary only has a reference to the framework's binary, which would be loaded in the memory at runtime. Assuming my understanding is correct, I'm stuck with the following problem: All 3 libs build successfully The framework builds successfully The main app target doesn't build. The compilation is successful, but the build fails with linker errors. Please let me know if I am doing something incorrectly, or if a configuration is missing. Below are more details: The linker gives the following error: Undefined symbols for architecture arm64: "StringUtils.GetStr() -> Swift.String", referenced from: dynamic_fw.AppDelegate.application(_: __C.UIApplication, didFinishLaunchingWithOptions: [__C.UIApplicationLaunchOptionsKey : Any]?) -> Swift.Bool in AppDelegate.o "TWUtils.GetNum() -> Swift.Int", referenced from: dynamic_fw.AppDelegate.application(_: __C.UIApplication, didFinishLaunchingWithOptions: [__C.UIApplicationLaunchOptionsKey : Any]?) -> Swift.Bool in AppDelegate.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) And the command shown in the logs for linking phase is: Ld /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Products/Debug-iphonesimulator/dynamic-fw.app/dynamic-fw normal (in target 'dynamic-fw' from project 'dynamic-fw') cd /Users/raunit.shrivastava/Desktop/dynamic-fw /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Xlinker -reproducible -target arm64-apple-ios17.5-simulator -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator17.5.sdk -O0 -L/Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/EagerLinkingTBDs/Debug-iphonesimulator -L/Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Products/Debug-iphonesimulator -L. -L./StringUtils -L./TWFramework -L./TWUtils -L./dynamic-fw -F/Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/EagerLinkingTBDs/Debug-iphonesimulator -F/Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Products/Debug-iphonesimulator -F. -F./StringUtils -F./TWFramework -F./TWUtils -F./dynamic-fw -filelist /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/Objects-normal/arm64/dynamic-fw.LinkFileList -Xlinker -rpath -Xlinker @executable_path/Frameworks -Xlinker -rpath -Xlinker ./\*\* -dead_strip -Xlinker -object_path_lto -Xlinker /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/Objects-normal/arm64/dynamic-fw_lto.o -Xlinker -export_dynamic -Xlinker -no_deduplicate -Xlinker -objc_abi_version -Xlinker 2 -fobjc-link-runtime -L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/iphonesimulator -L/usr/lib/swift -Xlinker -add_ast_path -Xlinker /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/Objects-normal/arm64/dynamic_fw.swiftmodule -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __entitlements -Xlinker /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/dynamic-fw.app-Simulated.xcent -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __ents_der -Xlinker /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/dynamic-fw.app-Simulated.xcent.der -framework TWFramework -Xlinker -no_adhoc_codesign -Xlinker -dependency_info -Xlinker /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Intermediates.noindex/dynamic-fw.build/Debug-iphonesimulator/dynamic-fw.build/Objects-normal/arm64/dynamic-fw_dependency_info.dat -o /Users/raunit.shrivastava/Library/Developer/Xcode/DerivedData/dynamic-fw-foqtqhpopkmoapfufzxbfloamnpr/Build/Products/Debug-iphonesimulator/dynamic-fw.app/dynamic-fw