The new MCP support for Coding Assistant in Xcode is a fantastic addition. It makes it much easier to work with AI directly inside Xcode, and it’s exciting to see Apple embracing AI-assisted development. However, many developers are now using external AI coding agents—such as Claude Code, Codex, and other terminal-based agents—as their primary development interface. In practice, much of the development workflow has shifted away from manually editing code in Xcode. Instead, developers collaborate with AI agents from the terminal (for example, using tmux), while the agents generate code, modify project settings, write tests, and perform many other development tasks. What these agents are missing is direct access to Xcode itself. It would be incredibly valuable if external AI coding agents could communicate with Xcode through an official MCP server, a CLI, or a dedicated automation API. For example, allowing them to: Build and run projects Control the iOS Simulator (or Device Hub) Launch and control Instruments Capture and analyze performance traces (Time Profiler, Leaks, Memory, SwiftUI, etc.) Inspect build errors, warnings, and diagnostics Access LLDB and debugging information Collect crash logs and symbolicated reports Perform other Xcode-specific operations that are currently only available through the IDE Imagine asking an AI agent to: “Profile my app with Instruments, find the performance bottleneck, explain the results, apply a fix, rebuild the app, and run the profiling session again to verify the improvement.” This would allow the AI to complete an entire development and optimization loop without requiring the developer to manually switch between the terminal and Xcode. The same idea could extend to many other workflows, including debugging, performance tuning, testing, accessibility verification, and simulator automation. Developers could continue using their preferred AI coding agent while still taking full advantage of Xcode’s unique capabilities. As AI-assisted development becomes more common, opening Xcode through an official MCP server, CLI, or automation API would unlock an entirely new class of development workflows. I believe this could become one of the most impactful improvements Apple could make for AI-assisted development. Today, AI agents are already capable of writing code. The next step is enabling them to fully collaborate with Xcode. Opening Xcode to external AI agents would allow developers to focus more on solving problems and less on operating tools.

Hello all, Yesterday, I found out that there's 60GB's of old simulator volumes on my mac in /Library/Developer/CoreSimulator/Volumes/. When I try to delete those through Xcode Settings -> Components under Other Installed Platforms, it looks like they are deleted, but after restarting my Mac, they simply return. I tried the solution proposed here (which is to delete the dmg files in /Library/Developer/CoreSimulator/Images/), but in my case, there are no dmg files in there. So it looks like they were properly deleted, unlike those in /Library/Developer/CoreSimulator/Volumes/. I could obviously try to delete the dmg files in /Library/Developer/CoreSimulator/Volumes/, but that doesn't work according to a post on reddit that I'm not allowed to show here (It's called 'Deleted 240GB of Xcode simulators multiple times but they keep remounting - how do I permanently remove them?') And I wonder if it's a safe thing to do. Do you have any suggestions for how to remove the old volumes correctly and permanently?

When using iOS 26.5 simulator to test my in-app purchase module, the products were loaded from my configuration file correctly, but calling purchase on the product would always return userCancellled outcome. Changing to iPhone15 + iOS 18 simulator resolved this issue.

Hi everyone, I'm exploring an idea for building an internal iOS test infrastructure and would appreciate some guidance on whether this is supported by Apple and complies with the Apple Developer Program terms. The idea is to have one or more Mac mini systems running Xcode and iOS Simulators on a private local network. Instead of engineers or CI systems interacting with the simulators directly on the Mac, they would connect to them remotely over the network to execute automated tests for an iOS application. The Mac minis and simulators would: Remain on my own premises. Be accessible only within a private/internal network (not exposed to the public internet). Be used solely for developing and testing an iOS application. My questions are: Is it supported to remotely access and control iOS Simulators over a private network for automated testing? Are there any licensing or Apple Developer Program restrictions that would prevent this type of setup? Are there any technical limitations or recommended best practices from Apple for building such an environment? I'm not asking about remote desktop access to the Mac itself. Instead, I'm interested in whether it's acceptable to expose a service running on the Mac that can manage simulator lifecycle (create, boot, shutdown, erase, etc.) and execute automation on behalf of clients over the network. If anyone from Apple or anyone who has built a similar setup can share guidance or point me to the relevant documentation, I'd really appreciate it. Thank you!

M4 Mac Mini: Xcode generates private keys with wrong label - codesigning impossible Background This is a follow up to my November 2024 thread "Keychain issues after installing backup on new Mac" which was closed because I had a temporary workaround. That workaround using my wife's MacBook Air for signing is not sustainable. I used AI assistance to determine the root cause. My DTS case 102877839447 is open but has not yet been forwarded to a DTS engineer. Environment Mac Mini M4, macOS 15.4.1 (Build 25E253) Xcode 26.4.1 (17E202) Team ID: Q23726668V (Computerade Products) Working comparison machine: MacBook Air, macOS 15.3 Precise Bug — Reproducible Every Time Every time Xcode generates a new certificate and key pair on my Mac Mini: Certificate: Apple Development: Michael Birch (9KD5TCGGHG) ✅ Private key: Apple Development: Michael Birch (Computerade Products) ❌ The key uses the organization name instead of the certificate identifier. They never pair as a valid codesigning identity. security find-identity -v -p codesigning always returns 0 valid identities. Cryptographic Evidence The internal application labels confirm the keys are cryptographically unrelated to their certificates: Key internal application label: 53C26EB056997276B5E938258D00665ACABD1F0F Certificate public key hash: 57cd1af4a9162f26b1a6d750e05a63a2166b75ff These do not match ❌ Confirmed Eliminated As Causes Keychain search list corruption — found and fixed Partition list — set correctly Access control — set to allow all applications Full Disk Access — granted to Xcode Xcode caches and preferences — completely cleared Login keychain — completely reset Orphaned certificates and keys — all removed SIP enabled, system fully up to date Valid P12 Import Also Fails A p12 exported from the working MacBook Air and cryptographically verified as a matched pair also fails on the Mac Mini: security import returns MAC verification failed Keychain Access import returns OSStatus -2 Importing certificate and key separately as PEM files succeeds but they are not recognized as a valid identity pair despite matching application labels A3F3F193B7896DA9055353F59AB450778CB09AE7 Question Is there a known issue with M4 Mac Mini keychain infrastructure where private keys are generated with incorrect internal application labels? Is there a lower level diagnostic or fix beyond what the security command provides? The problem is specific to my Mac Mini M4 and persisted thru more than a year of Mac OS and xCode updates.

The release notes at https://developer.apple.com/documentation/xcode-release-notes/xcode-27-release-notes mention that the minimum deployment target is macOS 11.0, but Xcode itself says that only macOS 12.0 to 27.0 are supported. Which one is correct, Xcode or the release notes? I created FB23514411.

Recently, with Xcode 26.6, we've been unable to install apps on some physical devices (iPhone, iPad). Some devices work fine. An alert saying "Install Application not available" appears. I reported it through Feedback Assistant, but someone from Apple replied that it's an issue with Xcode 27.0 beta and told me to install the latest Xcode 27. However, I'm actually using Xcode 26.6. The issue is still unresolved, so if anyone learns anything, I'd appreciate it if you could share an update.

Development environment: MacBook pro Apple M1 macOS Tahoe 26.2 (25C56) Xcode 26.x iPhone 6 Plus / iOS 12.4.4 Exception description: After I upgraded to Xcode 26, my iPhone 6 Plus had a system version of 12.4.4. I was unable to perform real-device debugging, whether for existing projects or new ones. The error message from Xcode was as follows: Could not launch “xxx” Domain: IDEDebugSessionErrorDomain Code: 3 Failure Reason: Cannot launch '/private/var/containers/Bundle/Application/A44062C1-32F5-4346-B13C-FC3F39EAF7A1/xxx.app': Unspecified Even though I have already added device support for the iOS 12.4 Has Xcode 26 stopped supporting the debugging of any devices running iOS 12 system?

Symptom Every build — both the Xcode IDE and command-line xcodebuild — hangs indefinitely at "Pre-planning"/"Planning N/M", before any compilation starts. The build log freezes for 40+ minutes with no progress and no error. Inspecting the stuck processes: The clang feature-detection probes (clang -v -E -dM -c /dev/null) sit at 0% CPU, blocked in write(). SWBBuildService is idle in swift_task_asyncMainDrainQueue → mach_msg — it never reads the probe output. Root cause: collapsed pipe buffers On this machine, anonymous pipe buffer capacity has dropped to 512 bytes (a healthy macOS pipe starts at 16 KB and expands to 64 KB on demand). SWBBuildService runs the clang feature-detection probe and reads its ~15 KB of output lazily (via Swift concurrency). With only a 512-byte buffer, the pipe fills instantly, clang's write() blocks forever, and the build deadlocks before it begins. swift build (SwiftPM) is unaffected because it drains subprocess pipes continuously in small reads — confirming the problem is the pipe buffer size, not the toolchain or compiler. The key detail — it's progressive, not constant (looks like a kernel pipe-KVA leak) This is the part that points at a kernel bug rather than a fixed config: Right after a reboot, a fresh os.pipe() measures 65536 bytes, and builds succeed normally. After ~50 minutes of normal build activity, the same measurement has monotonically degraded to 512 bytes, and builds hang again. So pipe capacity appears to leak down as pipe kernel-virtual-address (KVA) accounting accumulates during use. Notably, kern.ipc.maxpipekva does not exist as a sysctl OID on 26.5, so there's no tunable to raise the pool. Minimal diagnostic anyone can run import os, fcntl, errno r, w = os.pipe() fcntl.fcntl(w, fcntl.F_SETFL, os.O_NONBLOCK) total = 0 try: while True: total += os.write(w, b"x" * 256) except OSError as e: if e.errno != errno.EAGAIN: raise print("pipe capacity:", total, "bytes") Healthy machine: 16384+ (usually 65536). Affected machine: 512. When it reads 512, every xcodebuild will hang. What did NOT fix it (ruled out) Downgrading Xcode — tested Xcode 26.4.1 (17E202) via DEVELOPER_DIR: hangs identically. The trigger is the OS, not Xcode/Swift. Raising kern.ipc.maxpipekva — the OID doesn't exist on 26.5. Memory pressure (64 GB, 94% free, 0 swap), /etc/sysctl.conf / boot-time overrides, NVRAM boot-args, MDM/configuration profiles (not enrolled), third-party security/AV/DLP software (none installed), the project/packages, derivedData location, user Xcode prefs (clean HOME still hangs), connected devices. File-descriptor exhaustion — only ~87 pipe FDs were open, so it's not a count limit; it's per-pipe capacity. What does help Reboot restores 64 KB pipes — but only buys ~1 build before they degrade again. Temporary. Full in-place reinstall of macOS 26.5 resets pipe capacity (the incremental OTA may have left the system inconsistent), but the leak recurs with use. Staying on / reverting to macOS 26.4 is the only durable fix found, since 26.5 is the trigger. Question for Apple / others seeing this Has anyone else on 26.5 (25F71) confirmed pipe capacity degrading over time with the Python snippet above? This looks like a kernel pipe-KVA accounting leak introduced in 26.5. A separate, smaller issue is that SWBBuildService drains the clang probe pipe lazily, which turns a small pipe buffer into a hard deadlock instead of just slow I/O — a continuous-drain read would make Xcode resilient to it. Environment Mac Studio (Apple Silicon), 64 GB RAM macOS 26.5 (build 25F71) — problem began immediately after an incremental OTA update from 26.2 → 26.5 Xcode 26.5 (also reproduced on Xcode 26.4.1 / 17E202 — see below)

I have a Xcode 26.6, and when I run the simulators for iPhone, Siri does not work, Dictation does not work. I know my Mac microphone works just fine. It just seems like the simulator is not getting my voice input.

Currently running PacketLogger 15.4 with Sonoma 14.6.1 on a 2020 M1 Macbook Pro and am trying to log packets for a custom bluetooth device I have designed. I have used packetlogger in the past for the same device on this same laptop and had no issues seeing all advertised bluetooth packets from what seemed like every device in the office. It has been a few months and certainly a couple of OS updates but Packetlogger does not seem to log any packets at all anymore. I have made sure to clear all filters and to ensure I get all forms of bluetooth traffic. I have reinstalled the xcode developer tools as well and this has made no difference. I can clearly see the bluetooth advertising packets from my device using a ble scanner on my phone. Even trying to connect my phone over bluetooth to my laptop does not result in any logs. I am happy to provide more information as well as screenshots if need be. Thank You!

Following up on my last question, I noticed that when we build, if there's a failure to resolve package dependencies, if previously package dependency resolution succeeded, then the failure is not treated as an error but only as a warning.

I don't really know the terminology around this very well, but I was trying to test my Mac OS Catalyst app on Mac OS Sequoia, and the app kept crashing apparently due to MTL validation. I was trying to debug why using a menu (as in File, Edit, View, etc.) would crash. The stack looked roughly like this: 6 -[MTLDebugComputeCommandEncoder setBuffer:offset:attributeStride:atIndex:] MetalTools 5 _CF_forwarding_prep_0 CoreFoundation 4 ___forwarding___ CoreFoundation 3 -[NSObject doesNotRecognizeSelector:] CoreFoundation 2 objc_exception_throw libobjc.A.dylib 1 __cxa_throw b 0 _Unwind_RaiseException libunwind.dylib Both Claude and Gemini indicated that there was no flaw in my code, but rather that Xcode was responsible. Sure enough, unchecking the MTL validation checkbox in Xcode stopped the crash from happening.

This may be an Xcode problem not with SPM, but when I add a package into my App project, as a local package, whenever I change the dependencies of the package, even if the change to the version conflicts with the app's version constraints, the Xcode build the app just fine. I have to close and reopen the project again before the Xcode detects the change and raise an error during the build process. Why can't SPM/Xcode just detect the change while the app is opened, and raise an error instead of using whatever cache it is using? Currently, the workaround is to never edit the package in the app project (even though I should be able to), but to open the package as separate project to make edits, then reopen the app project to build the app. Another workaround I'm trying out is to add the xcodebuild -resolvePackageDependencies as a step during the build process, to force the build to cancel if theres package dependency resolution errors. But why is Xcode just ignoring resolution errors ??

We got the newly issue that our Test devices keeps us asking for the pin code to "Enable UI Automation". Then it works for some hours or days, but after some time it starts again. "Enable UI Automation" is already enabled in "Settings" - "Developer" menu. The devices are located remotely and we can't access them directly, so this is a big issue for us right now. Is there any way to avoid this?

The compiled size of my app (DerivedData/*/Build/Products/Debug-iphonesimulator/AppName.app) jumped 200 MB (926 MB-> 1.12 GB) just by compiling with Xcode 27 beta 2 (currently the latest). I can compile with Xcode 27, but when I run it on a simulator it crashes on launch. I get the same type of crash when running my unit tests. I'm getting a lot of warnings in the debug console about "Class X is implemented in both". I asked Claude to analyze the .app files to find the difference. Yes, I have a lot of internal and external packages/frameworks. Xcode26 ships 128 frameworks including 14 *_PackageProduct.framework dynamic frameworks (Logger_…, APICore_…, SplitManager_…, Apollo_…, PerModel_…, AppGateway_…, etc.). Xcode 27 ships 114 — all 14 of those dynamic package frameworks are gone. Xcode 27 changed the default and now links those SPM package products statically into every framework that consumes them. Counting framework binaries that carry their own copy of a package's Swift type metadata: ┌──────────────┬────────────┬─────────────┐ │ Package │ Xcode 26 │ Xcode 27 b2 │ ├──────────────┼────────────┼─────────────┤ │ Logger │ 12 │ 79 │ ├──────────────┼────────────┼─────────────┤ │ APICore │ 3 │ 45 │ ├──────────────┼────────────┼─────────────┤ │ SplitManager │ 1 │ 20 │ ├──────────────┼────────────┼─────────────┤ │ PerModel │ 1 │ 24 │ ├──────────────┼────────────┼─────────────┤ │ AppGateway │ 1 │ 20 │ └──────────────┴────────────┴─────────────┘ 79 copies of Logger's types instead of 1. That's the runtime problem: duplicate Swift type metadata / Objective-C class registration → "Class … is implemented in both …, one of the two will be used" and, when type identity or singletons matter, crashes. It hits unit tests hardest because the test bundle re-links the same static package that the host app's frameworks already contain. I worked on it a bit trying to switch my packages and frameworks to load dynamically. But that only gets so far as 3rd party packages like Apollo (for GraphQL) don't ship a dynamic version of ApolloTestSupport. I really don't like forking 3rd party packages. I tried changing my packages to explicitly load dynamically like this. That got me to the point that I could run on a simulator. But I was unable to get to the point that I could run all my unit tests without crashing on launch. And the code that runs on a simulator crashes on a device complaining about missing packages. products: [ .library( name: "AppGateway", + type: .dynamic, targets: ["AppGateway"]), ], Something is really different in Xcode 27 with the way it links packages and creates my app - a linker bug? I don't know if there is an ancient build setting that might be triggering this? Our app is really old. v1 was created in 2010. We just recently moved to a SceneUI delegate setup. I really don't know what would be a good next step for me to figure this one out. I am happy to use a DTS or create a Feedback if I thought it would help me get forward progress on this? Help?

I have an iOS project based on SwiftUI in which almost all code is organised in Packages. With Xcode 26.2 and 26.3, I can preview all SwiftUI views without issues. With Xcode 26.4, the same previews don't work, in the canvas appears this error message: "Cannot preview in this file. Could not find target description for “TaskListView.swift”". The explanation is: "The list of source files that produce object files did not contain this file to be previewed. Check to make sure it is not excluded using the EXCLUDED_SOURCE_FILE_NAMES build setting." If I add a SwiftUI view to the main project files (not in a package), the preview works as expected. Is it an Xcode 26.4 regression? Or do I need to modify some configuration file?

I am testing an app which reads text files from the documents directory on the Vision Pro. This was working for a while. Suddenly, after some edits, renaming a file and adding new test files. I only see the old files. How can I force Xcode to use the live directory at all times for testing.

Hi all, very new "developer" trying to build my own app. The app works, just trying to improve it. I’m implementing a Live Activity in a widget extension (Swift/SwiftUI) for an app built with Flutter as the host app. ActivityKit is functioning correctly—activities start, update, and end normally, and the widget extension receives all state updates. However, the Live Activity UI renders as a completely black capsule (both compact and expanded Dynamic Island, as well as the Lock Screen presentation). The system shows the Live Activity container, but none of the SwiftUI content displays. Verified so far: ActivityAttributes contains at least one stored property (previously empty). ContentState fully Codable + Hashable. All Dynamic Island regions return visible test UI (Text/Image). No .containerBackground() usage. Added explicit .activityBackgroundTint() + system foreground colors. All Swift files included in widget extension target. No runtime errors, no decode failures, no SwiftUI logs. Widget previews work. Clean build, app reinstall, device reboot. Entitlements and Info.plist appear valid. Problem: The widget extension returns a completely black UI on-device, despite valid SwiftUI content in ActivityConfiguration. The Live Activity “shell” renders, so the activity is recognized, but the widget’s view hierarchy is visually empty. Question: Under what conditions would a widget extension produce a black, empty UI for a Live Activity even when ActivityKit, previews, and the SwiftUI layout are correct? Are there known cases where: Widget extension Info.plist misconfiguration, Incorrect background/tint handling, Rendering issues in Dynamic Island, Host app integrations (Flutter), Or extension isolation issues cause valid SwiftUI to fail to render in a Live Activity? Any guidance on deeper debugging steps or known system pitfalls would be appreciated.

Hi, I'm experiencing a strange issue with iCloud Drive and Xcode on a Mac mini (Apple Silicon). Environment Mac mini (Apple Silicon) macOS Tahoe 26.5.2 Xcode 26.5 Symptoms Files in iCloud Drive Desktop stay at "Waiting to Update" for several days. Cloud icons never disappear. Moving projects from iCloud Drive Desktop to ~/Developer takes hours or never finishes. Existing Xcode projects stored in iCloud Drive open as a white "Loading..." screen forever. New Xcode projects work normally. Projects already moved to ~/Developer (for example one project) open and build normally. What I have already tried Restart Mac Updated to the latest macOS Cleared Xcode caches (DerivedData, Archives, old simulators) 132 GB free disk space killall fileproviderd killall bird brctl download brctl diagnose fileproviderctl check -P Logs After restarting fileproviderd, I continuously get messages like: Possible slow statement on SELECT ... scheduler not stable: jobs are running fetch-metadata ... is busy fileproviderd constantly uses around 70% CPU. Also, fileproviderctl check -P never completes. It stops at: "About to launch FPCK checks for 1 domains" and stays there for more than 10 minutes. Questions Has anyone experienced this with macOS Tahoe? Is this likely a CloudDocs/FileProvider database issue? Is there any safe way to repair the FileProvider database without risking iCloud data? Is there any way to identify or clear the stuck synchronization queue? Any advice would be greatly appreciated.