When looking ay space used by system, I found that AssetsV2 (in System/Library) account for 270 GB. In this folder, 3 account for 260 GB and are apparently related to Xcode simulators: Content is a bit cryptic. Does it relate to some specific apps I compiled and ran on simulator ? Or is it related to older versions of Xcode I keep on the Mac ? How to know what each forlder relates to ? Is it safe to remove ?

Apple’s library technology has a long and glorious history, dating all the way back to the origins of Unix. This does, however, mean that it can be a bit confusing to newcomers. This is my attempt to clarify some terminology. If you have any questions or comments about this, start a new thread and tag it with Linker so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" An Apple Library Primer Apple’s tools support two related concepts: Platform — This is the platform itself; macOS, iOS, iOS Simulator, and Mac Catalyst are all platforms. Architecture — This is a specific CPU architecture used by a platform. arm64 and x86_64 are both architectures. A given architecture might be used by multiple platforms. The most obvious example of this arm64, which is used by all of the platforms listed above. Code built for one platform will not work on another platform, even if both platforms use the same architecture. Code is usually packaged in either a Mach-O file or a static library. Mach-O is used for executables (MH_EXECUTE), dynamic libraries (MH_DYLIB), bundles (MH_BUNDLE), and object files (MH_OBJECT). These can have a variety of different extensions; the only constant is that .o is always used for a Mach-O containing an object file. Use otool and nm to examine a Mach-O file. Use vtool to quickly determine the platform for which it was built. Use size to get a summary of its size. Use dyld_info to get more details about a dynamic library. IMPORTANT All the tools mentioned here are documented in man pages. For information on how to access that documentation, see Reading UNIX Manual Pages. There’s also a Mach-O man page, with basic information about the file format. Many of these tools have old and new variants, using the -classic suffix or llvm- prefix, respectively. For example, there’s nm-classic and llvm-nm. If you run the original name for the tool, you’ll get either the old or new variant depending on the version of the currently selected tools. To explicitly request the old or new variants, use xcrun. The term Mach-O image refers to a Mach-O that can be loaded and executed without further processing. That includes executables, dynamic libraries, and bundles, but not object files. A dynamic library has the extension .dylib. You may also see this called a shared library. A framework is a bundle structure with the .framework extension that has both compile-time and run-time roles: At compile time, the framework combines the library’s headers and its stub library (stub libraries are explained below). At run time, the framework combines the library’s code, as a Mach-O dynamic library, and its associated resources. The exact structure of a framework varies by platform. For the details, see Placing Content in a Bundle. macOS supports both frameworks and standalone dynamic libraries. Other Apple platforms support frameworks but not standalone dynamic libraries. Historically these two roles were combined, that is, the framework included the headers, the dynamic library, and its resources. These days Apple ships different frameworks for each role. That is, the macOS SDK includes the compile-time framework and macOS itself includes the run-time one. Most third-party frameworks continue to combine these roles. A static library is an archive of one or more object files. It has the extension .a. Use ar, libtool, and ranlib to inspect and manipulate these archives. The static linker, or just the linker, runs at build time. It combines various inputs into a single output. Typically these inputs are object files, static libraries, dynamic libraries, and various configuration items. The output is most commonly a Mach-O image, although it’s also possible to output an object file. The linker may also output metadata, such as a link map (see Using a Link Map to Track Down a Symbol’s Origin). The linker has seen three major implementations: ld — This dates from the dawn of Mac OS X. ld64 — This was a rewrite started in the 2005 timeframe. Eventually it replaced ld completely. If you type ld, you get ld64. ld_prime — This was introduced with Xcode 15. This isn’t a separate tool. Rather, ld now supports the -ld_classic and -ld_new options to select a specific implementation. Note During the Xcode 15 beta cycle these options were -ld64 and -ld_prime. I continue to use those names because the definition of new changes over time (some of us still think of ld64 as the new linker ;–). The dynamic linker loads Mach-O images at runtime. Its path is /usr/lib/dyld, so it’s often referred to as dyld, dyld, or DYLD. Personally I pronounced that dee-lid, but some folks say di-lid and others say dee-why-el-dee. IMPORTANT Third-party executables must use the standard dynamic linker. Other Unix-y platforms support the notion of a statically linked executable, one that makes system calls directly. This is not supported on Apple platforms. Apple platforms provide binary compatibility via system dynamic libraries and frameworks, not at the system call level. Note Apple platforms have vestigial support for custom dynamic linkers (your executable tells the system which dynamic linker to use via the LC_LOAD_DYLINKER load command). This facility originated on macOS’s ancestor platform and has never been a supported option on any Apple platform. The dynamic linker has seen 4 major revisions. See WWDC 2017 Session 413 (referenced below) for a discussion of versions 1 through 3. Version 4 is basically a merging of versions 2 and 3. The dyld man page is chock-full of useful info, including a discussion of how it finds images at runtime. Every dynamic library has an install name, which is how the dynamic linker identifies the library. Historically that was the path where you installed the library. That’s still true for most system libraries, but nowadays a third-party library should use an rpath-relative install name. For more about this, see Dynamic Library Identification. Mach-O images are position independent, that is, they can be loaded at any location within the process’s address space. Historically, Mach-O supported the concept of position-dependent images, ones that could only be loaded at a specific address. While it may still be possible to create such an image, it’s no longer a good life choice. Mach-O images have a default load address, also known as the base address. For modern position-independent images this is 0 for library images and 4 GiB for executables (leaving the bottom 32 bits of the process’s address space unmapped). When the dynamic linker loads an image, it chooses an address for the image and then rebases the image to that address. If you take that address and subtract the image’s load address, you get a value known as the slide. Xcode 15 introduced the concept of a mergeable library. This a dynamic library with extra metadata that allows the linker to embed it into the output Mach-O image, much like a static library. Mergeable libraries have many benefits. For all the backstory, see WWDC 2023 Session 10268 Meet mergeable libraries. For instructions on how to set this up, see Configuring your project to use mergeable libraries. If you put a mergeable library into a framework structure you get a mergeable framework. Xcode 15 also introduced the concept of a static framework. This is a framework structure where the framework’s dynamic library is replaced by a static library. Note It’s not clear to me whether this offers any benefit over creating a mergeable framework. Earlier versions of Xcode did not have proper static framework support. That didn’t stop folks trying to use them, which caused all sorts of weird build problems. A universal binary is a file that contains multiple architectures for the same platform. Universal binaries always use the universal binary format. Use the file command to learn what architectures are within a universal binary. Use the lipo command to manipulate universal binaries. A universal binary’s architectures are either all in Mach-O format or all in the static library archive format. The latter is called a universal static library. A universal binary has the same extension as its non-universal equivalent. That means a .a file might be a static library or a universal static library. Most tools work on a single architecture within a universal binary. They default to the architecture of the current machine. To override this, pass the architecture in using a command-line option, typically -arch or --arch. An XCFramework is a single document package that includes libraries for any combination of platforms and architectures. It has the extension .xcframework. An XCFramework holds either a framework, a dynamic library, or a static library. All the elements must be the same type. Use xcodebuild to create an XCFramework. For specific instructions, see Xcode Help > Distribute binary frameworks > Create an XCFramework. Historically there was no need to code sign libraries in SDKs. If you shipped an SDK to another developer, they were responsible for re-signing all the code as part of their distribution process. Xcode 15 changes this. You should sign your SDK so that a developer using it can verify this dependency. For more details, see WWDC 2023 Session 10061 Verify app dependencies with digital signatures and Verifying the origin of your XCFrameworks. A stub library is a compact description of the contents of a dynamic library. It has the extension .tbd, which stands for text-based description (TBD). Apple’s SDKs include stub libraries to minimise their size; for the backstory, read this post. Use the tapi tool to create and manipulate stub libraries. In this context TAPI stands for a text-based API, an alternative name for TBD. Oh, and on the subject of tapi, I’d be remiss if I didn’t mention tapi-analyze! Stub libraries currently use YAML format, a fact that’s relevant when you try to interpret linker errors. If you’re curious about the format, read the tapi-tbdv4 man page. There’s also a JSON variant documented in the tapi-tbdv5 man page. Note Back in the day stub libraries used to be Mach-O files with all the code removed (MH_DYLIB_STUB). This format has long been deprecated in favour of TBD. Historically, the system maintained a dynamic linker shared cache, built at runtime from its working set of dynamic libraries. In macOS 11 and later this cache is included in the OS itself. Libraries in the cache are no longer present in their original locations on disk: % ls -lh /usr/lib/libSystem.B.dylib ls: /usr/lib/libSystem.B.dylib: No such file or directory Apple APIs, most notably dlopen, understand this and do the right thing if you supply the path of a library that moved into the cache. That’s true for some, but not all, command-line tools, for example: % dyld_info -exports /usr/lib/libSystem.B.dylib /usr/lib/libSystem.B.dylib [arm64e]: -exports: offset symbol … 0x5B827FE8 _mach_init_routine % nm /usr/lib/libSystem.B.dylib …/nm: error: /usr/lib/libSystem.B.dylib: No such file or directory When the linker creates a Mach-O image, it adds a bunch of helpful information to that image, including: The target platform The deployment target, that is, the minimum supported version of that platform Information about the tools used to build the image, most notably, the SDK version A build UUID For more information about the build UUID, see TN3178 Checking for and resolving build UUID problems. To dump the other information, run vtool. In some cases the OS uses the SDK version of the main executable to determine whether to enable new behaviour or retain old behaviour for compatibility purposes. You might see this referred to as compiled against SDK X. I typically refer to this as a linked-on-or-later check. Apple tools support the concept of autolinking. When your code uses a symbol from a module, the compiler inserts a reference (using the LC_LINKER_OPTION load command) to that module into the resulting object file (.o). When you link with that object file, the linker adds the referenced module to the list of modules that it searches when resolving symbols. Autolinking is obviously helpful but it can also cause problems, especially with cross-platform code. For information on how to enable and disable it, see the Build settings reference. Mach-O uses a two-level namespace. When a Mach-O image imports a symbol, it references the symbol name and the library where it expects to find that symbol. This improves both performance and reliability but it precludes certain techniques that might work on other platforms. For example, you can’t define a function called printf and expect it to ‘see’ calls from other dynamic libraries because those libraries import the version of printf from libSystem. To help folks who rely on techniques like this, macOS supports a flat namespace compatibility mode. This has numerous sharp edges — for an example, see the posts on this thread — and it’s best to avoid it where you can. If you’re enabling the flat namespace as part of a developer tool, search the ’net for dyld interpose to learn about an alternative technique. WARNING Dynamic linker interposing is not documented as API. While it’s a useful technique for developer tools, do not use it in products you ship to end users. Apple platforms use DWARF. When you compile a file, the compiler puts the debug info into the resulting object file. When you link a set of object files into a executable, dynamic library, or bundle for distribution, the linker does not include this debug info. Rather, debug info is stored in a separate debug symbols document package. This has the extension .dSYM and is created using dsymutil. Use symbols to learn about the symbols in a file. Use dwarfdump to get detailed information about DWARF debug info. Use atos to map an address to its corresponding symbol name. Different languages use different name mangling schemes: C, and all later languages, add a leading underscore (_) to distinguish their symbols from assembly language symbols. C++ uses a complex name mangling scheme. Use the c++filt tool to undo this mangling. Likewise, for Swift. Use swift demangle to undo this mangling. For a bunch more info about symbols in Mach-O, see Understanding Mach-O Symbols. This includes a discussion of weak references and weak definition. To remove symbols from a Mach-O file, run strip. To hide symbols, run nmedit. It’s common for linkers to divide an object file into sections. You might find data in the data section and code in the text section (text is an old Unix term for code). Mach-O uses segments and sections. For example, there is a text segment (__TEXT) and within that various sections for code (__TEXT > __text), constant C strings (__TEXT > __cstring), and so on. Over the years there have been some really good talks about linking and libraries at WWDC, including: WWDC 2023 Session 10268 Meet mergeable libraries WWDC 2022 Session 110362 Link fast: Improve build and launch times WWDC 2022 Session 110370 Debug Swift debugging with LLDB WWDC 2021 Session 10211 Symbolication: Beyond the basics WWDC 2019 Session 416 Binary Frameworks in Swift — Despite the name, this covers XCFrameworks in depth. WWDC 2018 Session 415 Behind the Scenes of the Xcode Build Process WWDC 2017 Session 413 App Startup Time: Past, Present, and Future WWDC 2016 Session 406 Optimizing App Startup Time Note The older talks are no longer available from Apple, but you may be able to find transcripts out there on the ’net. Historically Apple published a document, Mac OS X ABI Mach-O File Format Reference, or some variant thereof, that acted as the definitive reference to the Mach-O file format. This document is no longer available from Apple. If you’re doing serious work with Mach-O, I recommend that you find an old copy. It’s definitely out of date, but there’s no better place to get a high-level introduction to the concepts. The Mach-O Wikipedia page has a link to an archived version of the document. For the most up-to-date information about Mach-O, see the declarations and doc comments in <mach-o/loader.h>. Revision History 2025-06-29 Added information about autolinking. 2025-05-21 Added a note about the legacy Mach-O stub library format (MH_DYLIB_STUB). 2025-04-30 Added a specific reference to the man pages for the TBD format. 2025-03-01 Added a link to Understanding Mach-O Symbols. Added a link to TN3178 Checking for and resolving build UUID problems. Added a summary of the information available via vtool. Discussed linked-on-or-later checks. Explained how Mach-O uses segments and sections. Explained the old (-classic) and new (llvm-) tool variants. Referenced the Mach-O man page. Added basic info about the strip and nmedit tools. 2025-02-17 Expanded the discussion of dynamic library identification. 2024-10-07 Added some basic information about the dynamic linker shared cache. 2024-07-26 Clarified the description of the expected load address for Mach-O images. 2024-07-23 Added a discussion of position-independent images and the image slide. 2024-05-08 Added links to the demangling tools. 2024-04-30 Clarified the requirement to use the standard dynamic linker. 2024-03-02 Updated the discussion of static frameworks to account for Xcode 15 changes. Removed the link to WWDC 2018 Session 415 because it no longer works )-: 2024-03-01 Added the WWDC 2023 session to the list of sessions to make it easier to find. Added a reference to Using a Link Map to Track Down a Symbol’s Origin. Made other minor editorial changes. 2023-09-20 Added a link to Dynamic Library Identification. Updated the names for the static linker implementations (-ld_prime is no more!). Removed the beta epithet from Xcode 15. 2023-06-13 Defined the term Mach-O image. Added sections for both the static and dynamic linkers. Described the two big new features in Xcode 15: mergeable libraries and dependency verification. 2023-06-01 Add a reference to tapi-analyze. 2023-05-29 Added a discussion of the two-level namespace. 2023-04-27 Added a mention of the size tool. 2023-01-23 Explained the compile-time and run-time roles of a framework. Made other minor editorial changes. 2022-11-17 Added an explanation of TAPI. 2022-10-12 Added links to Mach-O documentation. 2022-09-29 Added info about .dSYM files. Added a few more links to WWDC sessions. 2022-09-21 First posted.

I sometimes use Xcode 14.2. Recently, I have an issue with simulators: on some SwiftUI project, the simulator list is empty. I created a new project. I see the complete list of simulators, but when running for a simulator, it fails with following diag; Same error with UIKit project. Details Unable to boot the Simulator. Domain: NSPOSIXErrorDomain Code: 60 Failure Reason: launchd failed to respond. User Info: { DVTErrorCreationDateKey = "2025-06-29 06:16:35 +0000"; IDERunOperationFailingWorker = "_IDEInstalliPhoneSimulatorWorker"; Session = "com.apple.CoreSimulator.SimDevice.134EC197-BA6B-45DF-B5B2-61A1D4F14863"; } -- Failed to start launchd_sim: could not bind to session, launchd_sim may have crashed or quit responding Domain: com.apple.SimLaunchHostService.RequestError Code: 4 -- Analytics Event: com.apple.dt.IDERunOperationWorkerFinished : { "device_model" = "iPhone15,2"; "device_osBuild" = "16.2 (20C52)"; "device_platform" = "com.apple.platform.iphonesimulator"; "launchSession_schemeCommand" = Run; "launchSession_state" = 1; "launchSession_targetArch" = "x86_64"; "operation_duration_ms" = 8341; "operation_errorCode" = 60; "operation_errorDomain" = NSPOSIXErrorDomain; "operation_errorWorker" = "_IDEInstalliPhoneSimulatorWorker"; "operation_name" = IDERunOperationWorkerGroup; "param_consoleMode" = 0; "param_debugger_attachToExtensions" = 0; "param_debugger_attachToXPC" = 1; "param_debugger_type" = 3; "param_destination_isProxy" = 0; "param_destination_platform" = "com.apple.platform.iphonesimulator"; "param_diag_MainThreadChecker_stopOnIssue" = 0; "param_diag_MallocStackLogging_enableDuringAttach" = 0; "param_diag_MallocStackLogging_enableForXPC" = 1; "param_diag_allowLocationSimulation" = 1; "param_diag_checker_tpc_enable" = 1; "param_diag_gpu_frameCapture_enable" = 0; "param_diag_gpu_shaderValidation_enable" = 0; "param_diag_gpu_validation_enable" = 0; "param_diag_memoryGraphOnResourceException" = 0; "param_diag_queueDebugging_enable" = 1; "param_diag_runtimeProfile_generate" = 0; "param_diag_sanitizer_asan_enable" = 0; "param_diag_sanitizer_tsan_enable" = 0; "param_diag_sanitizer_tsan_stopOnIssue" = 0; "param_diag_sanitizer_ubsan_stopOnIssue" = 0; "param_diag_showNonLocalizedStrings" = 0; "param_diag_viewDebugging_enabled" = 1; "param_diag_viewDebugging_insertDylibOnLaunch" = 1; "param_install_style" = 0; "param_launcher_UID" = 2; "param_launcher_allowDeviceSensorReplayData" = 0; "param_launcher_kind" = 0; "param_launcher_style" = 0; "param_launcher_substyle" = 0; "param_runnable_appExtensionHostRunMode" = 0; "param_runnable_productType" = "com.apple.product-type.application"; "param_runnable_type" = 2; "param_testing_launchedForTesting" = 0; "param_testing_suppressSimulatorApp" = 0; "param_testing_usingCLI" = 0; "sdk_canonicalName" = "iphonesimulator16.2"; "sdk_osVersion" = "16.2"; "sdk_variant" = iphonesimulator; } -- System Information macOS Version 12.7.1 (Build 21G920) Xcode 14.2 (21534) (Build 14C18) Timestamp: 2025-06-29T08:16:35+02:00 I filed a bug report: FB18475006

I have a small playground approx 150 lines no SwiftUI It also has a 70 line text file Xcode now thinks I have over 4000 files that have changed and they are Xcode or system files If I am looking at this list then the Mac Mini will freeze with a frozen mouse, just a stuck mouse pointer. After a minute or so the Mac will reboot itself. Any suggestions as to how to fix this would be appreciated. I have already reinstalled Xcode and the tools and its still the same.

I am trying to integrate fastlane, which relies on xcodebuild. So this is my first experience with xcodebuild. Whenever I run a command to test or build the target in the folder where all the files of the project are stored, the action failes with Unable to find a device matching the provided destination specifier For example I might be running this command: xcodebuild \ -project Hoerspielzentrale.xcodeproj \ -scheme HoerspielzentraleUITests \ -destination 'platform=iOS Simulator,name="Screenshot Simulator”' \ test However the mentioned error is returned: xcodebuild: error: Unable to find a device matching the provided destination specifier: { platform:iOS Simulator, OS:latest, name:"Screenshot Simulator” } The requested device could not be found because no available devices matched the request. I can confirm that the simulator exists, is available and it can be booted. I have tried different simulators, different schemas, referencing them by their identifier, switching Xcode Versions, reset all simulators, derived data and build folder. After the error a complete list of all available destinations can be found, where I can see the simulator I try to use. Available destinations for the "HoerspielzentraleUITests" scheme: { platform:iOS, id:dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder, name:Any iOS Device } { platform:iOS Simulator, id:dvtdevice-DVTiOSDeviceSimulatorPlaceholder-iphonesimulator:placeholder, name:Any iOS Simulator Device } { platform:iOS Simulator, id:961DC569-9931-419A-B46E-769AAFA73EA2, OS:18.5, name:Screenshot Simulator } { platform:iOS Simulator, id:961DC569-9931-419A-B46E-769AAFA73EA2, OS:18.5, name:Screenshot Simulator } { platform:iOS Simulator, id:5E51FD98-C451-472F-9CDE-08D49E6B737B, OS:18.5, name:Screenshot Simulator Pro } { platform:iOS Simulator, id:5E51FD98-C451-472F-9CDE-08D49E6B737B, OS:18.5, name:Screenshot Simulator Pro } The rest of the list was omitted. I am currently completely stuck. Thank you

I've been experimenting with using local LLMs in place of ChatGPT in coding assistant. I was able to do this using LM Studio. I found that switching LLMs was a little clunky, but eventually, I was able to make it work. However, none of the LLMs I tried were able to generate error free Swift code. Not surprising at this stage. I decided to train an LLM (Llama3.1-8b) with Apple's Swift Programming language reference, using Open WebUI, and this worked. I was able to get the LLM to generate working Swift Code that I was able to test in Playgrounds. The problem I'm having now is that Xcode is locked up on the last LLM I tried out. I've tried deleting all the LLM providers in Settings, leaving only ChatGPT, but Xcode still defaults to the local LLM, even though it throws errors if you try to ask it a question. I've tried reinstalling Xcode, downloading new versions of sample Xcode projects, and deleting various data files, all to no avail. I would really like to test the new LLM I've trained in coding assistant, but right now, Xcode won't let me. It won't even let me revert to ChatGPT.

Any idea what this message means? I assume it's coming from CloudKit, but the application seems to store and retrieve data properly.

Xcode failed to provision this target. Please file a bug report at https://feedbackassistant.apple.com and include the Update Signing report from the Report navigator. Provisioning profile "iOS Team Provisioning Profile: com.OctaneBuddy.ios" doesn't include the com.apple.developer.foundation-models entitlement. Getting pretty upset at not being able to deploy and test on my phone :/ Works just fine with another project/app though.

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 added a new liquid glass icon built with Icon Composer to my app. It works and looks great on iOS 26 but Xcode complains that required icon files for older versions are missing. I still have the old AppIcon in my Asset Catalog but it seems like it's not being used. How do I configure Xcode to use the old icons for iOS 18 and the new icon for iOS 26?

I am testing the Music API and I am hitting walls every single moment when I try to do something that is DOCUMENTED but doesn't work/exists. Documentation says, /v1/catalog/us/artists/{ID}/view/{view}/ NEVER returns 404, while I am getting 404 for even content I know it's available on Apple Music. e.g /v1/catalog/us/artists/1487603897/view/appears-on-albums/ results 404 while they are appearing on an album FRIGID ******* of Nosphere artist. So when I request for appears-on or featured albums it shoud appear as a result, but I get 404. It's here so it should appear: https://music.apple.com/us/album/frigid-silence/1791001624?i=1791001626 I found NO WAY to get that album for this artist using the API, which is very frustrating and annoying. Similarly if I try this: /v1/catalog/us/artists/{ID}?views=>appears-on-albums it will result an EMPTY array for the data property Also the documentation is unclear about the several limitation max values, many parameters (e.g. include parameters are unknown ) we can't tell what value can we use. Is Apple Music Api unreliable or I just don't understand something?! I don't even understand why I have to do 4 different requests to get an artists all albums (full, single, featured, appears-on)... this should be MUCH more easier to do it one single request (with pagination). We are working on a long-term major investment in music startup and trying to move from Spotify API (due to recent changes and limitations) and finding a better alternative. Based on the docs Apple Music API seemed the most promising one, but now we are testing it we are very disappointed so far. So should we trust in this or should we forget about Apple Music API?

Using xcode 26 with linker flag -ld_classic，get an error ： 0 0x1042b9778 __assert_rtn + 160 1 0x1042bc560 ld::tool::SymbolTableAtom<x86_64>::classicOrdinalForProxy(ld::Atom const*) (.cold.3) + 0 2 0x1041f3da8 ld::tool::SymbolTableAtom<x86_64>::classicOrdinalForProxy(ld::Atom const*) + 172 3 0x1041f4c1c ld::tool::SymbolTableAtom::addImport(ld::Atom const*, ld::tool::StringPoolAtom*) + 140 4 0x1041f6500 ld::tool::SymbolTableAtom::encode() + 396 5 0x1041e83a8 ___ZN2ld4tool10OutputFile20buildLINKEDITContentERNS_8InternalE_block_invoke.413 + 36 6 0x182a95b2c _dispatch_call_block_and_release + 32 7 0x182aaf85c _dispatch_client_callout + 16 8 0x182acc478 _dispatch_channel_invoke.cold.5 + 92 9 0x182aa7fa4 _dispatch_root_queue_drain + 736 10 0x182aa85d4 _dispatch_worker_thread2 + 156 11 0x182c49e28 _pthread_wqthread + 232 A linker snapshot was created at: /tmp/app-2025-06-13-215652.ld-snapshot ld: Assertion failed: (it != _dylibToOrdinal.end()), function dylibToOrdinal, file OutputFile.cpp, line 5196. clang++: error: linker command failed with exit code 1 (use -v to see invocation)

I have a project that uses local SPM packages for modularization. In one of my local SPM packages I have a .storyboard file that gets packaged as a resource in the SPM package and consumed inside the parent. In Xcode 15.4, the resource bundle for my local SPM Package has the bundle id PackageName-TargetName-resources. I use this inside a parent storyboard to reference the storyboard from the SPM package. In Xcode 16, however, the resource bundle for my SPM Package gets assigned the bundle id packagename.TargetName.resources. This, of courses, introduces a crash in builds of my app done with Xcode 16 due to the incorrect bundle id. There is no documentation of this change that I could find by Apple or by the SPM team. Apple Team: There is a Feedback Report FB14803020 with the build files attached from Xcode 15.4 and Xcode 16. I cannot attach those here due to the public nature of this forum

When I import both AppIntents and MediaPlayer in the same file, I get the error “No such module '_MediaPlayer_AppIntents’” To reproduce: Create a new project with Xcode 26 beta, selecting storyboard UI and swift language. In ViewController.swift add import AppIntents and import MediaPlayer Build Get the error: “No such module '_MediaPlayer_AppIntents’” Submitted as FB18189693

On my MacBook Pro M4 with macOS 15.5 and Xcode 16.4, I have a simple SwiftUI-based WatchOS application consisting of a NavigationSplitView that displays a short List of items, and a detail view consisting of a TabView {...}.tabViewStyle(.verticalPage) that displays a fixed number of "pages" of detailed information about the selected list item. When I use XCTest UI Automation with XCUIApplication(), I am finding that I need to add a sleep(1) after every interaction, such as a .tap() or .swipeUp() before I can attempt any assertion such as XCTAssertGreaterThan(app.cells.count, 3) to ensure that the top level List of items is more than 3. All the added sleep(1) statements are making the tests very slow... It appears that the WatchOS implementation of UI Automation lacks the ability to wait until the UI event queue is idle. Am I the only one seeing this?

I'm getting this error, don't really understand why... Showing All Errors Only Build Archive Export archive for ad-hoc distribution Command exited with non-zero exit-code: 70 Command exited with non-zero exit-code: 70 Export archive for development distribution Command exited with non-zero exit-code: 70 Command exited with non-zero exit-code: 70 Export archive for app-store distribution Command exited with non-zero exit-code: 70 Command exited with non-zero exit-code: 70 Activity Log Complete 6/26/25, 10:06 PM 0.4 seconds

When I run the debug memory graph from Xcode I'm getting a set of system objects with warnings. Are there any tips on how to locate what might be causing these?

My experience with Swift 6 strict concurrency so far doesn't match my understanding of implicit MainActor isolation semantics. This is a cross-post from StackOverflow. I will link answers between both forums. TL;DR Build succeeds when testing a struct declared in the test module, but fails when the struct is moved to the main module: Main actor-isolated property … cannot be accessed from outside the actor. Steps to reproduce Open up Xcode 26 beta 2 on macOS 26 (probably also ok on current stables). Create a new Swift app with Swift testing, no storage. Call it WhatTheSwift. Set the Swift Language Version on all three targets to Swift 6. Update the default test file to be this: import Testing @testable import WhatTheSwift struct WhatTheSwiftTests { @Test func example() async throws { let thing = Thing(foo: "bar") #expect(thing.foo == "bar") } } struct Thing { let foo: String } That should build fine, and the tests should pass. Now, move the Thing declaration into its own Thing.swift file in the WhatTheSwift module, and try running the test again. You should see this: Observations Marking the test @MainActor allows the test to pass, suggesting the compiler actually wants to isolate Thing.foo to the main actor. My question Why? And why only when Thing is in a different module?

Crash while trashing an opened and pinned file. This crashing can be reproduced. Xcode Version 26.0 beta 2 (17A5241o) Part Of Crash Log

What is the policy for data sharing when using Coding Intelligence in Xcode 26? In many environments, sending out source code or even meta data that may be stored in external systems is not allowed. Is there any kind of policy on data persistency / sharing when using the default provider? Is there a way to limit data sharing apart from running models locally?