I'm running in a very very very weird error. I have a large asset catalog, consisting of about 2700 assets for 1.19GB of size. I can successfully build and run my project with both release and debug scheme, when a real device or simulator is selected. However, whenever I select Any iOS device (arm64), about 80ish seconds in the build process, the building fails with the following output: CoreUI: Error: unable to add asset to store *** Terminating app due to uncaught exception 'IBPlatformToolFailureException', reason: 'The tool closed the connection (AssetCatalogSimulatorAgent) What I tried and failed: Cleaning DerivedData and restarting PC Building the same project on three different devices, each with a different version of XCode. All failed. running sudo killall -9 com.apple.CoreSimulator.CoreSimulatorService Scanning for duplicate image files, found none. Scanning for duplicate .imageset folders in different folders, found none. Scanning for images that declared a different format than theirs, eg .webp renamed as .png, and found none. Creating an empty Hello World project, and just adding my asset catalog. Build fails for Any iOS device, succeeds for simulator or physical device. Uninstalling and reinstalling XCode command line tools. Manually compiling via actools. Changed "Embed Assets Pack in Product Bundle" from No to Yes. I don't have any .svg file in my assets. What I tried and failed but gives more insight: Now the only thing that I was able to come up with was deleting folders to narrow down where the problem was. So I found that there is a 700MB folder called T, containing T1, T2, ..., T6. Eventually managed to narrow down even more to T3, T4, T6. I created a distinct .xcassets catalog for each subfolder and tried to compile individually with actools, along with assets.xcassets (the main one). Here's the thing: T3.xcassets + assets.xcassets compiles T4.xcassets + assets.xcassets compiles T6.xcassets + assets.xcassets compiles T3.xcassets + T4.xcassets + assets.xcassets compiles. T3.xcassets + T6.xcassets + assets.xcassets compiles. T4.xcassets + T6.xcassets + assets.xcassets compiles. T3.xcassets + T4.xcassets + T6.xcassets + assets.xcassets crashes with CoreUI: Error: unable to add asset to store. I've been stuck for days now and can't deploy my finished app I worked on for the last three years because of this.

I have a project that leverages XPC and has interoperability between Swift and Objective-C++. I am presently getting a compile-time error in one of our unit test targets, of "Argument passed to call that takes no arguments" on the following code: let interface = NSXPCInterface(with: XPCServiceDelegate.self) My XPCServiceDelegate protocol is defined as: @objc(XPCServiceDelegate) public protocol XPCServiceDelegate { //... } For the longest time, this code has compiled successfully, and it has not recently changed. There are two confusing things about this error. The first is that I have a different build scheme that will compile correctly other code with the same structure. The other is that I have team members that are able to compile my failing scheme successfully on the same XCode version, OSVersion, and branch of our repository. I've attempted numerous things to try to get this code to compile, but I've run out of ideas. Here's what I've tried: Clean build both on XCode 16.4 and XCode 26 Beta Delete DerivedData and rebuild on XCode 16.4 and XCode 26 Beta Delete and re-clone our git repository Uninstall and reinstall XCode Attempt to locate cached data for XCode and clear it out. (I'm not sure if I got everything that exists on the system for this.) Ensure all OS and XCode updates have been applied. The interface specification for NSXPCInterface clearly has an initializer with one arguement for the delegate protocol, so I don't know why the compiler would fail for this. Is there some kind of forward declaration or shadowing of NSXPCInterface? Do you have any ideas on what I could try next?

After uprgading to new XCode version 26.0.1 my project can't be longer build. There are strange compiler errors without concrete error message. If I want to investigate the single errors they disappears on selection... I can send a recorded screen-video. I invested over 2 weeks on trying to solve the problem without success. That's not the first time that the project couldnt be build after a xcode upgrade. Thats really annoying.

After upgrading to macOS Tahoe 26.0.1, I encountered an issue where the debugger could no longer display standard C++ library types such as std::map, std::string, and other std:: containers. Instead, the debugger simply showed: Summary Unavailable 🧪 What I Tried • Switched from the default LLVM compiler to GDB to check if it was a debugger-related problem — no improvement. • Cleaned and rebuilt the project — the issue persisted. ✅ Solution Downgrading Xcode to version 16.4 immediately resolved the issue. According to Apple’s official Xcode support documentation, Xcode 16.4 is compatible with macOS Sequoia 15.6 and later, which includes macOS Tahoe 26.0.1. This suggests that the problem may be caused by a compatibility issue in the latest Command Line Tools bundled with newer versions of Xcode. 💡 Takeaway If you encounter the same problem: 1. Try downgrading to Xcode 16.4 or reinstalling the corresponding Command Line Tools. 2. Make sure your debugger (LLDB or GDB) is correctly linked to the appropriate SDK version. Hopefully this helps anyone experiencing the same issue!

After upgrading to macOS Tahoe 26.0.1, I encountered an issue where the debugger could no longer display standard C++ library types such as std::map, std::string, and other std:: containers. Instead, the debugger simply showed: Summary Unavailable 🧪 What I Tried • Switched from the default LLVM compiler to GDB to check if it was a debugger-related problem — no improvement. • Cleaned and rebuilt the project — the issue persisted. ✅ Solution Downgrading Xcode to version 16.4 immediately resolved the issue. According to Apple’s official Xcode support documentation, Xcode 16.4 is compatible with macOS Sequoia 15.6 and later, which includes macOS Tahoe 26.0.1. This suggests that the problem may be caused by a compatibility issue in the latest Command Line Tools bundled with newer versions of Xcode. 💡 Takeaway If you encounter the same problem: Try downgrading to Xcode 16.4 or reinstalling the corresponding Command Line Tools. Make sure your debugger (LLDB or GDB) is correctly linked to the appropriate SDK version. Hopefully this helps anyone experiencing the same issue!

Hello everyone, Since I installed Xcode 26, I've been encountering issues I've never seen before. I have Mac OS applications written in Objective-C, some released as far back as 14 years ago. When compiling them with Xcode 26, I experience efficiency issues related to thread management and interface updates. There are rendering problems with a simple NSTextView created through Interface Builder. The issue is not easily reproducible as it occurs randomly on some machines, regardless of their architecture or macOS version. The main thread freezes, and generally after 15-30 seconds, it unfreezes, loading the interface and text. The length of the text is irrelevant to the issue, and no crashes occur. I spent ten days trying to optimize the code and change the loading order within the class, but the problem persists. However, if I compile the application with Xcode 16.4, everything works like a charm. I also tried using the macOS 15.5 SDK to compile with Xcode 26, but it doesn’t resolve any issues. Additionally, I tried changing the compiler optimization level, but it didn’t solve the problem. This leads me to believe it’s an issue with the Xcode 26 compiler. If it were a code issue, it would be easily reproducible and would also occur when compiling with 16.4. The Xcode 26.1 Beta doesn’t resolve the issue. Can anyone tell me if I need to change something related to the compiler? Are you aware of any issues like this? Thank you, Luca

"/Users/rich/Work/IdeaBlitz/IdeaBlitz/IdeaListView.swift:30:25 The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions" Is it just me? I get this on syntax errors, missing commas, missing quotes, and for no particular reason at all that I can see. I don't think I've been able to write a single, simple, SwiftUI view without seeing this multiple times. "Breaking it up" just makes it harder to read. Simple, inline, 2-page views become 8-page, totally unreadable, monstrosities. Am I doing something wrong? Or is this just the state of SwiftUI today? Or is there some way to tell the compiler to take more time on this expression? I mean, if these can be broken up automatically, then why doesn't the compiler to that already?

The following C code shows different results when build in debug or release mode with Xcode 26.0.1. #include <stdio.h> static void print_fval(int16_t *src) { float fval = (float)((((int32_t)*src) << 16) - (1 << 31)); printf("fval: %f\n", fval); } int main(int argc, const char * argv[]) { int16_t i16[1] = { 0 }; print_fval(i16); return EXIT_SUCCESS; } In debug mode the output is: fval: -2147483648.000000. In release mode the output is: fval: 2147483648.00000. The 1 << 31 might be questionable but I would expect the same outcome in debug or release mode. The difference is in compiling with optimizations or not, compiler option -O0 vs any other optimization option. Would this be considered a compiler/optimizer bug? Older versions of Xcode (15.4 and earlier) do not have this problem.

In my app target Foo, I have a dependency on package Bar. Bar itself have a dependency on another package Other. In my test target FooTests, I have a dependency on package BarTestsHelpers. BarTestsHelpers depends on Bar. When compiling test target FooTests, I get the following unexpected warning in Xcode 26 only: 'Bar' is missing a dependency on 'Other' because dependency scan of Swift module 'Bar' discovered a dependency on 'Other' I can see this is being discussed here as well without a solution. I filled a feedback with a sample project here: FB20602885 It seems that we can remove the warning by explicitly adding the dependency Other on BarTestHelpers. But this shouldn't be needed as BarTestHelpers doesn't use nor know about Other, it only needs it as part of its dependency on Bar.

App Icon created with Icon Composer is empty for visionOS app We are developing a universal app, and the app’s icon was created using Icon Composer. Xcode 26, RC visionOS 26 and visionOS 2.5 App Icons on macOS, iOS, and iPadOS are correct We have archived the app for macOS and iOS and successfully uploaded it to the App Store. This strongly suggests that the App Icon configuration in our project settings is correct for these platforms. App Icon issue on visionOS However, the visionOS app icon is not working as expected: When testing on the Vision Pro simulator (versions 2.x and 26.0), the app icon appears empty. When archiving and submitting to the App Store, the process fails with the following error: The app’s Info.plist file is missing the CFBundleIcons.CFBundlePrimaryIcon key for the visionOS App Icon. This suggests that the project’s App Icon settings may not be correctly applied for visionOS builds. Request for assistance We are preparing to release our app, one of the first to support Liquid Glass, and would greatly appreciate guidance on how to resolve this issue with the visionOS app icon. FB20184218

My book env: MacBook Air Apple M4 15.6.1 (24G90) I installed JDK hs_err_pid6813.log by sdkman and homebrew, but when I ran java, os crashed: /opt/homebrew/o/openj/libexec/openjdk.jdk/Contents/Home/bin | stable ./javac --verison ABRT | 12:32:20 # # A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0x000000010211b340, pid=7237, tid=9987 # # JRE version: (21.0.7) (build ) # Java VM: OpenJDK 64-Bit Server VM (21.0.7, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64) # Problematic frame: # V [libjvm.dylib+0x35f340] CodeHeap::allocate(unsigned long)+0x15c # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /opt/homebrew/Cellar/openjdk@21/21.0.7/libexec/openjdk.jdk/Contents/Home/bin/hs_err_pid7237.log # # [1] 7237 abort ./javac --verison Does that mean I have to reinstall OSX?

I'm trying to compile a simple hello world C++ program on my MacBook Pro. I have a M3 Pro (Nov 2023) running Sequoia 15.6. The program is: #include &lt;iostream&gt; int main() { std::cout &lt;&lt; "Hello World!"; return 0; } The error I get is: In file included from test.cpp:1: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/iostream:42: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/ios:220: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__locale:15: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__memory/shared_ptr.h:13: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__compare/compare_three_way.h:13: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__compare/three_way_comparable.h:12: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/__compare/common_comparison_category.h:15: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/cstddef:42:5: error: &lt;cstddef&gt; tried including &lt;stddef.h&gt; but didn't find libc++'s &lt;stddef.h&gt; header. This usually means that your header search paths are not configured properly. The header search paths should contain the C++ Standard Library headers before any C Standard Library, and you are probably using compiler flags that make that not be the case. 42 | # error &lt;cstddef&gt; tried including &lt;stddef.h&gt; but didn't find libc++'s &lt;stddef.h&gt; header. \ | ^ However, I can see stddef.h in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/ and in /usr/local/include

I have a multi target project where every target relies on a built "web bundle" which is basically a collection of html, optimized images, and optimized javascript. Right now that web bundle is built in a pre build step by running a script. The script takes awhile to run and outputs to a folder that is referenced into the project via a PBXFileReference which is then referenced in the Copy Bundle Resources step. 96516AC22BF928DD00576562 /* build */ = {isa = PBXFileReference; lastKnownFileType = folder; name = build; path = "../web-ui/build"; sourceTree = "<group>"; } .... 96516AC32BF928DD00576562 /* build in Resources */ = {isa = PBXBuildFile; fileRef = 96516AC22BF928DD00576562 /* build */; }; As a step, I wrote an aggregate target that can also run this script. I specified its input and output files and turned off sandboxing. It does exactly what I need it to. Critically it is ran based on dependency analysis. If I modify any file in web-ui it rebuilds, if I dont I can repeatedly build the aggregate target and it will not re-run the script. This is perfect. A97590172E419CBA00741928 /* Build Web Bundle */ = { isa = PBXShellScriptBuildPhase; buildActionMask = 12; files = ( ); inputFileListPaths = ( ); inputPaths = ( "$(SRCROOT)/xcodescripts/build-web-bundle.bash", "$(SRCROOT)/web-ui/index.html", "$(SRCROOT)/web-ui/vite-env.d.ts", "$(SRCROOT)/web-ui/vite.config.ts", "$(SRCROOT)/web-ui/tsconfig.json", "$(SRCROOT)/web-ui/stats.html", "$(SRCROOT)/web-ui/postcss.config.js", "$(SRCROOT)/web-ui/package.json", "$(SRCROOT)/web-ui/justfile", "$(SRCROOT)/web-ui/src/", ); name = "Build Web Bundle"; outputFileListPaths = ( ); outputPaths = ( "$(SRCROOT)/web-ui/build/", ); runOnlyForDeploymentPostprocessing = 0; shellPath = /bin/sh; shellScript = "exec \"${SCRIPT_INPUT_FILE_0}\"\n"; }; You may notice I reference a src file. This is made possible via a flag USE_RECURSIVE_SCRIPT_INPUTS_IN_SCRIPT_PHASES which allows Xcode to check folder dependencies recursively. The problem is that my other targets do not automatically recognize that they need to run the "WebBundle" aggregate target in order to update a resource they copy in their "Copy bundle resources" phase. So I tried adding it as a Target Dependency. A9DE685B2E41C9A8005EF4E0 /* PBXTargetDependency */ = { isa = PBXTargetDependency; target = A97590132E419C1200741928 /* WebBundle */; targetProxy = A9DE685A2E41C9A8005EF4E0 /* PBXContainerItemProxy */; }; Unfortunately this breaks whatever magic was allowing the script to be run only when there are web bundle changes. Every build it runs the "Build Web Bundle" script. I think what I am missing is a way to specify in these other targets that a resource they are used to copying from the Xcode PBXFileReference is produced by the aggregate target. This way they can start to reason about the dependencies. Other possibilities are that I should be building the web bundle to a separate location. Or that these references are somehow broken in another way. To be clear the folder format is as thus project/ iOS/ client.xcodeproj web-ui/ build/ (web bundle build is output here and referenced relatively) src/ index.html (and other things)

By default, AppleClang adds /usr/local/include to the application search folders for include files (as opposed to the system include dirs). This causes problems with the expected include order because application search folders always have priority over system includes. Specifically it causes problems with the conan package manager as library includes are added with -isystem This behaviour differs from LLVM mainline clang and GCC, where /usr/local/include is a system include (added with -internal-isystem). Steps to reproduce - run echo 'int main() { return 0; }' | clang -xc -v - the output is as follows Apple clang version 17.0.0 (clang-1700.0.13.5) Target: arm64-apple-darwin24.5.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" ... -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -I/usr/local/include -internal-isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include ...

Hello! I'm developing a GPU (shader) language, where I aim to target multiple backends with a common frontend. I wanted to avoid having to round trip through Metal, and go straight to IR just like I have with SPIRV, in order to have a fast and efficient compilation process. I've been looking for a reference page where I can read about Metals IR, and as far as I'm aware, it exists, but I can't seem to find it anywhere. Furthermore, if such a reference is available, is there also a toolkit where I can run validation on the output IR, and perhaps even run optimizations, much like spv-tools for SPIRV? Any help would be appreciated! Thanks, Gustav

The Java Swing and AWT MVC model made it easy to develop complex UIs with data interactions that were not described readily in a nested layer that SwiftUI demands. The implicit update model of SwiftUI greatly complicates development of applications that often requires nested components to have to know too much about other components and other structures than their own, because button events and other user interactions cannot readily alter state across layers. A button push on one component then has to be knowledgable about state in other components which have to have that state represented as @State or @Binding etc. and this causes all kinds of wiring to be spread all over the place rather than have a more centralized "state management function" that would be able to look at the world and synchronize the UIs state across changes. The fact that the compiler get's lost in the weeds when types and signatures don't match in deeper component structures doesn't help because it makes it doubly hard to do refactoring to raise and lower state management within the structure readily, because the compiler just cannot simply tell you that a function or constructor signature is no longer correct.

Again and and again, I reach the point in a new application where I need to make structural changes in components and my data model, and the SwiftUI compiler fails to compile and just reports "I'm lost in the weeds", with no indication of what it was last working on, aside from a particular level in a multi-layered nested UI. This typically happens when a sub-views construction is not coded correctly because I changed that view and am looking for what broke, by just letting the compiler tell me what is not compatible. This is how refactoring has been done for ages and it's just amazingly frustrating that Apple engineers don't seem to understand nor care about this issue enough to fix it. Why does this problem persist through version after version of SwiftUI? Is no-one actually using it for anything?

Dear all, For an important client, we are currently experiencing issues related to performance IOS build using Xcode Cloud. More in detail, their build process is taking approximately 30 minutes to complete at the moment, whereas the same build executed locally on a Mac machine takes around 7 minutes. This significant difference in build times is causing concerns and slowing down the development work. We would appreciate your support in identifying possible causes and exploring different ways to improve the actual situation (ex if it is possible to increase the Cloud machine calculation power). Could you please advise us on how we might proceed to analyze and potentially optimize the build times on Xcode Cloud? What kind of processors are used? Any guidance, best practices, or diagnostic steps you can suggest would be greatly appreciated. Looking forward to your support.

I have my project running perfectly fine on Xcode 16. However, in Xcode 26 it doesn't build due to an error that I do not understand. I have three files that pertain to this error: // FriendListResponse.swift import Foundation struct FriendListResponse: Decodable { var friendships: [Friendship] var collections: [FriendCollection] } // Friendship.swift import Foundation struct Friendship: Decodable { var createdAt: String var friendId: Int var friendUserId: Int // user ID of the friend var friendUsername: String var id: Int var tagNames: [String] } // FriendCollection.swift struct FriendCollection: Decodable { var id: Int var permalink: String var tagNames: [String] var title: String } On the first file, FriendListResponse.swift, I am the simple error message "circular reference." I do not understand how these self-contained structs could create a circular reference. Although I have other data types in my project, none of them are even referenced in these files except for Friendship and FriendCollection. The FriendListResponse is a struct that is created from JSON values that are fetched from an API. This is the function that fetches the JSON: public static func listFriends(username: String) async throws -> [Friendship] { let data = try await sendGETRequest( url: "people/\(username)/friends/list.json" ) print(String(data: data, encoding: .utf8)!) let decoder = JSONDecoder() decoder.keyDecodingStrategy = .convertFromSnakeCase let wrapper = try decoder.decode(FriendListResponse.self, from: data) return wrapper.friendships } // Note: the function sendGETRequest is just // a function that I have created that takes a set // of parameters and returns a data object // using the HTTP GET protocol. I don't think // that it is related to this issue. However, if you // think that it is, I can share the code for that. This error has also happened in a few other cases within contained networks of my data structure. I do not know why this error is only appearing once I launch Xcode 26 beta with my project files. I would think that this error also would appear in Xcode 16.4. Any help would be greatly appreciated in my process to compile my project on Xcode 26!

Hi, I encountered an issue in my code where I directly used #import <CoreHaptics/CoreHaptics.h> without adding it to the "Link Binary With Libraries" section under Build Phases. My deployment target is iOS 12, and the code was running fine before; however, after upgrading Xcode, the app crashes immediately on an iOS 12 device with the following error message: DYLD, Library not loaded: /System/Library/Frameworks/CoreHaptics.framework/CoreHaptics | xx | Reason: image not found. Did Xcode modify the default auto-linking configuration? When did this behavior change in which version of Xcode? Do I need to specify CoreHaptics.framework as Optional in "Link Binary With Libraries"? Thanks for reply soon!