I have an orphaned asset folder taking up 9.13GB located at: /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/c0d3fd05106683ba0b3680d4d1afec65f098d700.asset It contains SimulatorRuntimeAsset version 18.5 (Build 22F77). Active Version: My current Xcode setup is using version 26.2 (Build 23C54). I checked the plist files in the directory and found what seems to be the cause of the issue: The "Never Collected" Flag: The Info.plist inside the orphaned asset folder explicitly sets the garbage collection behavior to "NeverCollected": <key>__AssetDefaultGarbageCollectionBehavior</key> <string>NeverCollected</string> The Catalog Mismatch: The master catalog file (com_apple_MobileAsset_iOSSimulatorRuntime.xml) in the parent directory only lists the new version (26.2). Because the old version (18.5) is missing from this XML, Xcode and mobileassetd seem to have lost track of it entirely. What I Have Tried (All Failed) Xcode Components: The version 18.5 does not appear in Settings -> Components, so I cannot delete it via the GUI. Simctl: xcrun simctl list runtimes does not list this version. Running xcrun simctl runtime delete 22F77 fails with: "No runtime disk images or bundles found matching '22F77'." Manual Deletion: sudo rm -rf [path] fails with "Operation not permitted", presumably because /System/Library/AssetsV2 is SIP-protected. Third-party Tools: Apps like DevCleaner do not detect this runtime (likely because they only scan ~/Library or /Library, not /System/Library). Has anyone found a way to force the system (perhaps via mobileassetd or a specific xcrun flag) to re-evaluate this folder and respect a deletion request? I am trying to avoid booting into Recovery Mode just to delete a cache file. Any insights on how AssetsV2 handles these "orphaned" files would be appreciated.

Does the annually updated requirement that apps uploaded to App Store Connect must be built with the latest SDK (i.e. Xcode version) only apply to the main executable or to embedded binaries (e.g. frameworks) also?

Neither in Xcode 27 beta 1 or 2 we have been able to use simulators for the intel x86 architecture. Is there any way to get them?

I can sign into AppStore Connect from Chrome, not sometimes in Safari. I get an error dialog that says The operation couldn’t be completed. Unable to log in with account ''. An unexpected failure occurred while logging in (Underlying error code -1001). Apple servers all seem up, so it's just me apparently

Summary: Xcode 26.5 on macOS 26.5.1 (25F80) does not record recently opened projects. The Welcome window permanently shows "No Recent Projects" regardless of how many projects are opened. Open recent projects menu item no longer exists in new versions. Only on welcome. Steps to Reproduce: Launch Xcode 26.6 on macOS 26.5.1 Open an existing .xcodeproj or .xcworkspace file by double-clicking in Finder Close the project Open the Welcome window (Shift+Cmd+1 or via Window menu) Expected Result: The recently opened project appears in the Recent Projects list. Actual Result: The Welcome window shows "No Recent Projects". The keys IDERecentEditorDocuments and IDERecentWorkspaceDocuments in com.apple.dt.Xcode.plist remain empty or absent after opening projects. Diagnostic Steps Already Taken: Confirmed com.apple.quarantine xattr removed from Xcode plist Confirmed Full Disk Access granted to Xcode Confirmed plist is writable (no uchg flag, correct ownership) Deleted com.apple.dt.Xcode.plist entirely and allowed Xcode to recreate it — issue persists Confirmed ApplePersistenceIgnoreState is not set globally or per-app Confirmed NSGlobalDomain ApplePersistenceIgnoreState is not set Projects are opened by double-clicking physical .xcodeproj files in Finder (not aliases or symlinks) Environment: Xcode Version: 26.5 macOS Version: 26.5.1 (Build 25F80) Hardware: MacBook Pro

Environment • macOS 27 beta 2 • Xcode 27 beta • Apple Silicon Mac Summary After upgrading to macOS 27 beta 2 and Xcode 27 beta, an old iOS 18.5 simulator runtime remains registered internally but cannot be removed. There appears to be an inconsistency between different CoreSimulator commands. Observed Behavior xcrun simctl runtime list only reports the current runtime: == Disk Images == -- iOS -- iOS 26.1 (23B86) - 0753590B-CF3F-4944-899E-4F70698DB87C (Ready) Total Disk Images: 1 (7.8G) However, xcrun simctl list runtimes -j still reports an additional runtime: identifier: com.apple.CoreSimulator.SimRuntime.iOS-18-5 SimulatorVersion: 18.5 Build: 22F77 bundlePath: /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime runtimeRoot: /Library/Developer/CoreSimulator/Volumes/iOS_22F77/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.5.simruntime/Contents/Resources/RuntimeRoot The runtime is reported as: "isAvailable": true The runtime no longer appears anywhere in Xcode. Attempting to remove it using the documented command fails: xcrun simctl runtime delete 22F77 Output: No runtime disk images or bundles found matching '22F77'. No matching images found to delete Using the runtime identifier also fails. The corresponding MobileAsset still exists: /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/ It contains: c0d3fd05106683ba0b3680d4d1afec65f098d700.asset Its Info.plist contains: SimulatorVersion = 18.5 Build = 22F77 Another asset exists for the current runtime: SimulatorVersion = 26.1 Build = 23B86 The directory /Library/Developer/CoreSimulator/Volumes/iOS_22F77 exists as an empty directory. It appears to become active only when CoreSimulator queries the runtime. The runtime asset is no longer referenced by /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/com_apple_MobileAsset_iOSSimulatorRuntime.xml Expected Result After upgrading Xcode/macOS: • old runtimes should either be removable through xcrun simctl runtime delete or • they should no longer remain registered if Xcode has already removed them. Actual Result Different CoreSimulator commands report different runtime states. simctl runtime list only reports iOS 26.1. simctl list runtimes -j still reports iOS 18.5 as available. The old runtime cannot be deleted using the official command. The MobileAsset remains on disk and occupies storage, but there appears to be no supported method to remove it. Notes This looks like CoreSimulator's runtime registry and the runtime deletion mechanism have become inconsistent after upgrading to macOS 27 beta 2 and Xcode 27 beta.

If I use the Claude Code agent within Xcode 27 beta 2, it defaults to Opus 4.8, but that burns through tokens too quickly so I'd like to switch it to Opus 4.7 or Sonnet, but there's no way to change that anywhere in Xcode that I can see? Also, if I use Chat, rather than the agent, then Xcode lets you select models, however for Claude it only offers Sonnet 4.5. Why? Why not 4.6 at least? Where are these limitations coming from? It's not from Claude so it must be Xcode Why are these limitations present?

My app start up has became horrid. It takes 1 minute to open SQLlite database for my rust core. Impossible to work... I have Address Sanitizer, Thread Perf Checker and Thread Sanitizer disabled...

I have had two kernel panics while building in Xcode, or running extremely simple interactions with a single Swift Double in playgrounds in Xcode. Has any one else seen this while building in Xcode? For whatever it is worth, Gemini states it is not a hardware problem, but something to do with "aggressive memory security protocols to support modern unified architectures and stricter platform boundaries", and that this is a an assertion error in Darwin. Given that this happened twice over the last three days, I'm a little concerned. Thanks in advance Hardware: M5 Max with 129 GB, and ~720 GB of storage First incident configuration (while building in Xcode): Xcode: 26.5 MacOS: 26.5.1 Second incident configuration (while running a playground in Xcode): Xcode: Version 26.6 (17F113) MacOS: 26.5.2 Second incident (looks like an underflow in Core 0): "bug_type":"210", ..., "os_version":"macOS 26.5.2 (25F84)", "roots_installed":0, ... "product" : "Mac17,6", "kernel" : "Darwin Kernel Version 25.5.0: ... "socRevision" : "11", "panicString" : "panic(cpu 0 caller 0xfffffe0051dde6fc): vm_object_activity_end(0xf3fffe14df4d2e00): underflow ... @vm_object_internal.h:700 Debugger message: panic Memory ID: 0xff OS release type: User OS version: 25F84 Kernel version: Darwin Kernel Version 25.5.0: ... Exclaves boot status: BOOTED_EXCLAVEKIT Fileset Kernelcache UUID: 5311854233360499876BA3DD5FD3C710 Kernel UUID: BEA0911B-FF13-3AE9-816D-8DEF9DD951DF ... roots installed: 0 Paniclog version: 15 CORE 0 is the one that panicked. Check the full backtrace for details. CORE 1: PC=0xfffffe0051d5e7e0, LR=0xfffffe0051e5dc3c, FP=0xfffffecffaf33af0 CORE 2: PC=0xfffffe0051d14b6c, LR=0xfffffe0051d14b6c, FP=0xfffffec34a8f7ee0 ...

Please help me understand how build SDKs work in Xcode 27. Let's say I have an older app that uses UIDesignRequiresCompatibility. When I a) select an iOS 26 Simulator in Xcode 27 and press "play" (build an run), the app shows up in design compatibility mode. b) select an iOS 27 Simulator in Xcode 27 and press "play" (build an run), the app shows up ignoring design compatibility mode. My questions: Does that mean a) is using iOS 26 as build SDK and b) is using iOS 27 as build SDK? What would happen if running an app built using iOS 26 build SDK on iOS 27? What would happen if running an app built using iOS 27 build SDK on iOS 26? How can 2. and 3. be done with the simulator? When I submit to App Store Connect, which build SDK is used?

We root-caused a launch crash that only affects ARCHIVED builds (Run/Debug works, simulator works) and filed it as FB23528109. Posting the details here because the crash signatures are hard to search for and other teams are likely to hit this as they adopt Swift 6.3 toolchains. SYMPTOM The archived app crashes before main() on device, on every launch. Depending on which orphaned pointer gets read first, the crash looks like one of these: EXC_BREAKPOINT, "pointer authentication trap DA", inside swift_conformsToProtocolMaybeInstantiateSuperclasses / _searchConformancesByMangledTypeName (often with a Firebase or other +load frame below it; that frame is just the first conformance scan at launch, not the cause) EXC_BAD_ACCESS KERN_INVALID_ADDRESS at a small, raw unslid address (e.g. 0xc118), inside dyld: resolveRebase <- objc_visitor::forEachClass <- dyld4::PrebuiltObjC::make Debug builds, simulator builds and Xcode Run builds are all fine, because the corruption happens in the Strip build phase, which only runs for Archive/install builds. ROOT CAUSE (two defects combine) strip -S -T (what Xcode runs on embedded frameworks during Archive when STRIP_SWIFT_SYMBOLS = YES) corrupts dyld chained fixups. When strip removes a Swift weak-definition symbol that has a GOT bind, it converts the bind into a rebase to the local definition (correct) but writes the converted entry with next = 0 (incorrect). That terminates the 16 KB page's fixup chain early, and every fixup after the converted slot in the same page is orphaned: dyld never processes it, so raw chain-encoding bytes get read as pointers at launch. The bug is present in every strip we tested: Xcode 26.3, 26.4, 26.4.1, 26.5, 26.6 and 27.0 beta 2. strip -S and strip -S -x (without -T) do not corrupt. Starting with Swift 6.3.0 (Xcode 26.4.0), the compiler emits the trigger pattern for ordinary code: cross-module references to a non-final class's stored-property accessors become weak-def-coalesce binds (Swift 6.2.4 emits none). So apps that embed a multi-module Swift dynamic framework (e.g. an SPM package built as one dynamic framework) started getting corrupted by their own default Archive pipeline when they moved past Xcode 26.3. HOW TO CHECK IF YOU ARE AFFECTED Compare the fixups of a framework binary inside your archive against a Run build of the same code: xcrun dyld_info -fixups YourApp.app/Frameworks/YourKit.framework/YourKit If fixups that exist in the Run build are missing after the archive's strip step (in particular __got slots and anything after them in the same 16 KB page), you are affected. Also: any GOT bind of a Swift ($s...) symbol in the pre-strip binary is a red flag. WORKAROUND Set STRIP_SWIFT_SYMBOLS = NO (optionally STRIP_STYLE = non-global, i.e. strip -S -x, which kept the size cost to about +4% for us). Important: if the affected framework is a Swift package product, these must be passed as xcodebuild command-line overrides (e.g. xcodebuild ... STRIP_SWIFT_SYMBOLS=NO STRIP_STYLE=non-global); xcconfig files do not apply to package targets. REPRO FB23528109 contains a complete minimal reproducer (4 small C files + 1 trivial Swift file, no proprietary code): a 30-second CLI script whose host binary segfaults through an orphaned pointer, and a default-settings Xcode project whose Run build works while its archived build crashes pre-main on device, identically for archives produced by Xcode 26.3.0, 26.4.0 and 26.6 (crash logs for each attached in the FB). Happy to share more details from the investigation if anyone is debugging the same signatures.

Working with Agents in Xcode 27 is a nightmare right now. Every conversation opens in a new window, so you don't see the code you and the agent are working on. You have to go back and forward between the code file and the conversation tab to get the names of data types or functions you need to ask the agent to work on, or to see exactly what you need to ask or how to explain it to the agent. We need the conversation and the code to be side by side to be able to work on the code and provide the right instructions, as we do in Xcode 26. The current interface just completely ruins any reasonable workflow, unless you are vibe coding, which I don't recommend. Let me know if there is a way to open the conversation on one side and code files on the other, or PLEASE change it back of what it was before or I will have to keep working on Xcode 26 and miss all the new features. Thanks

Hi guys In Xcode 27, we have to create the Assets Catalog file ourselves. This file is empty. The icon now is generated by Icon Composer, but how do you specify the accent color? I tried creating a Color set with the name AccentColor but didn't work. And look for options in the project settings but couldn't find any.

I found that Xcode 26.1.1 (17B100) silently disables UICollectionView self-sizing configured in Interface Builder, depending on the minimum deployment target. I've fixed this issue in my project by explicitly setting the estimatedItemSize to UICollectionViewFlowLayout.automaticSize, but I was wondering whether this is intended behavior, or am I missing something? When a XIB contains a UICollectionViewFlowLayout with Estimate Size: Automatic (automaticEstimatedItemSize="YES" in the document source): <collectionViewFlowLayout key="collectionViewLayout" scrollDirection="horizontal" automaticEstimatedItemSize="YES" minimumLineSpacing="6" minimumInteritemSpacing="6"> <size key="itemSize" width="128" height="32"/> </collectionViewFlowLayout> ibtool drops the estimated-size key from the compiled nib if IPHONEOS_DEPLOYMENT_TARGET is 17.0 or later. It can be confirmed by compiling the same XIB at two deployment targets: $ ibtool --target-device iphone --minimum-deployment-target 16.0 --compile out16.nib View.xib $ strings out16.nib | grep -i estimat estimatedItemSize # present $ ibtool --target-device iphone --minimum-deployment-target 17.0 --compile out17.nib View.xib $ strings out17.nib | grep -i estimat # (nothing - key is gone) At runtime the flow layout decodes estimatedItemSize = .zero, so self-sizing is silently disabled and every cell is laid out at the placeholder Cell Size (128x32 above), regardless of its content: decoded estimatedItemSize = (0.0, 0.0), itemSize = (128.0, 32.0) // target 17.0 decoded estimatedItemSize = (1.79e+308, 1.79e+308) // target 16.0, works This is independent of the runtime OS version — I reproduced it on iOS 18.4 and iOS 26.1 simulators. The information is simply missing from the compiled nib, and no build warning or error is emitted. Confusingly, UIKit still calls the cell's preferredLayoutAttributesFitting(_:), so cells appear to compute correct sizes; they are just never adopted by the layout, which makes this quite hard to debug. Workaround — set it in code after the nib loads (the XIB cannot be fixed at the source level because the attribute is dropped at compile time): (collectionView.collectionViewLayout as? UICollectionViewFlowLayout)?.estimatedItemSize = UICollectionViewFlowLayout.automaticSize I attached minimal reproduction project (toggle IPHONEOS_DEPLOYMENT_TARGET between 16.0 and 17.0 to see both behaviors) to the feedback filed as FB23526517

Hi, I'm trying to figure out what is true here - if I am not in the correct forum please direct me :-) A. It is not possible to test a QR code scan that contains a deeplink into my iOS app from an XCoode build test run. In other words, The build must be published to Test Flight for the iOS's QR code scan sub-system to be able to process the deeplink into my app? If I am wrong about this, it sure would help with testing to be able to test directly from the local XCode build test. If so, can someone point me in the direction of what I would need to do for that? Thanks for your input either way!

Im unable to deploy Xcode 27 beta code to an iPhone 17 pro The build is successful but its not loading

我用Xcode自动下载无法下载Metal工具 我重启了我的Mac 使用命令行工具安装仍然失败 尝试使用了日本VPN结果一样但是准备阶段时间变长了

This forced network connection severely affects the development efficiency. No matter how you implement communication, when you plug in a USB device, you must and definitely prioritize using USB. If you always use the network or rely on the mobile network card, it will interfere with the efficiency of the policy for connecting via the mobile network. When there are many people in our company sharing a Wi-Fi network and it is already very slow, it is impossible to debug this, which is extremely annoying. Why do you have to prohibit developers from setting whether to debug through USB or the network? You can't figure it out because your network is fast. When your network is congested, it is completely unusable. Why not let them choose for themselves? I don't understand why you have to hide this switch. It is very stupid.

I'm trying to build the DriverKit template driver target in an Xcode project which contains an app targeting iPadOS 17. I've made no modifications to the DriverKit template. When building, I get this link error ld: file cannot be open()ed, errno=2 path=/Applications/Xcode 15.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a in '/Applications/Xcode 15.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.profile_driverkit.a' anyone know how to fix this? My search turned up something about building llvm from sources, which seems like overkill to put a DriverKit driver into an iPad app.

Xcode 27 creates a placeholder for the bundle identifier of a new project. devplaceholder.$(PROJECT_UNIQUE_VALUE:identifier).$(PRODUCT_NAME:identifier) I have two questions. Is it enough to change the bundle id from the Signing & Capabilities panel or do we need to change it somewhere else? What are Apple recommendations? Should we only replace the devplaceholder value and keep the unique value and product name, provide our won id but keep the product name, or replace everything with our own bundle ID? Thanks