Dear Xcode Team, Please consider adding an option to position the Coding Assistant on the right side of the editor. Currently, when the assistant panel is open, it makes it difficult to access the Project Navigator at the same time. Having the ability to move the Coding Assistant to the right side would allow developers to keep the Project Navigator visible while interacting with the assistant, improving workflow and efficiency. Thank you

Filed a feature request in feedback assistant, but starting a discussion here as well since I'm probably not the only one. The issue I have is that coding assistant and previews seem to be mutually exclusive. That means that when I'm iterating on UI, I either have to rely on the coding assistant showing me preview screenshots (cannot interact), firing up Device Hub (have to manually kick off a build after each change) or manually opening the associated preview (requires a lot of hoping back and forth). This feels inefficient and means I have to hop around and manage my windows and tabs more. A slight work around is to open a split view with the file and preview there. This layout is inefficient and clunky. I would love if Xcode supported a pinned preview next to coding assistant (or automatically showed the relevant one). I imagine this working just like showing a preview next to a file cmd + opt + return hides/shows the preview. FB23219611

All my Xcode 27 versions (including Xcode 27.2. beta 2) have this strange Build & Run icon with a line through it. What does it mean and how can i change it? Screenshots of Xcode 27 in the App Store and the WWDC 27 videos show the normal triangle and no slash. Does anyone else see this on their Xcode 27? I works without problems, everything is normal, just this strange slash bothers me. Update: The official 27.1 release version has the normal triangle. It looks like this is for beta versions?

Environment: Xcode 27 (macOS 27.0, build 26A428) iOS 27.0 simulator (build 24A434), tested on iPhone 18 Pro CoreSimulator 1174.9.2 Large app target: dozens of linked frameworks (first-party SPM modules plus several third-party SDKs) it occurred on xcode 26 also Description: SwiftUI canvas previews consistently crash XCPreviewAgent with EXC_BAD_ACCESS / SIGSEGV when rendering previews for a fairly large app target, across multiple different SwiftUI views (not tied to one specific file's code). Workaround found: the crash does not occur when "Use Legacy Preview Execution" is enabled (Xcode's preview settings). With the default (non-legacy, JIT-based) preview execution path, it crashes reliably; switching to legacy execution, previews render normally. Possible contributing factor — project size / timing: we suspect the size of the project may also be a factor, independent of the crash itself. The new (non-legacy) execution path recompiles/JITs the app for the canvas on every preview, and for a target this large that process takes noticeably longer than it does under legacy execution. It's plausible that on top of the crash described below, the new path is also more prone to timing out or failing under load on larger projects, simply because there's more to JIT-compile and load within whatever time budget the preview agent allows. We can't fully separate "crashes because of X" from "runs out of time because of project size" from the crash logs alone, but both seem worth flagging since they may share the same root cause in the new execution path's handling of larger binaries. Crash signature #1 (default preview execution, first attempts): Crashing Thread: 0 libswiftCore.dylib swift_conformsToProtocolMaybeInstantiateSuperclasses(...) 1 libswiftCore.dylib swift_conformsToProtocolWithExecutionContext 2 libswiftCore.dylib swift::_conformsToProtocol(...) 3 libswiftCore.dylib swift::_checkGenericRequirements(...) Termination: SIGSEGV / Segmentation fault: 11 Crash signature #2 (default preview execution, after removing an unrelated third-party SDK dependency from the previewed module, to rule it out as a cause): Crashing Thread ("com.apple.xojit_executor.wrapper_functions"): 0 libobjc.A.dylib readClass(objc_class*, bool, bool) 1 libobjc.A.dylib map_images_nolock 2 libobjc.A.dylib map_images 3 libobjc.A.dylib _objc_map_images 4-7 <unsymbolicated / anonymous image, source="A" (Absent) in the crash report> Exception: EXC_BAD_ACCESS (SIGSEGV), KERN_INVALID_ADDRESS In the second case, the crash log's usedImages list shows the frames above the objc runtime resolving to an image with no path, no resolvable UUID, and "source": "A" — this appears to be the dynamically JIT-compiled preview binary that XOJITExecutor builds and hot-loads for the canvas (rather than a normal on-disk framework), and the crash occurs while the Objective-C runtime is registering classes from it during _objc_map_images. What we've ruled out: Not caused by the specific SwiftUI view being previewed — reproduces across multiple unrelated views in the same target. Not caused by a specific third-party SDK: we removed a heavyweight closed-source analytics SDK dependency from the previewed module entirely (confirmed via successful xcodebuild build with zero references left), and the crash still occurred with an equivalent signature under default preview execution. Confirmed via symbolicated .ips crash reports in ~/Library/Logs/DiagnosticReports/XCPreviewAgent-*.ips that the crashing frames are inside Apple's own preview infrastructure (libobjc.A.dylib, libswiftCore.dylib, XOJITExecutor), not in application or third-party framework code. Confirmed the failure is specific to the new (non-legacy) preview execution path: enabling "Use Legacy Preview Execution" eliminates the crash entirely, with no other changes. Question for the community: Has anyone else seen SwiftUI Previews crash with a libobjc/map_images or swift_conformsToProtocol* segfault specifically on Xcode 27 / iOS 27 simulator with the new (non-legacy) preview execution path, for apps with a large number of linked frameworks? Does project size/build time make the new execution path more likely to fail or time out for anyone else? Is "Use Legacy Preview Execution" the recommended workaround until this is fixed, or should this be filed separately as Feedback?

Hi, I'm trying to run our StoreKit unit tests with Xcode26.5 on an iOS26.5 simulator. Host computer has macOS26.5. All tests are failing and in the console I see logs such as [SKTestSession] Error saving configuration file: Error Domain=SKInternalErrorDomain Code=3 "(null)" [SKTestSession] Error deleting all transactions: Error Domain=SKInternalErrorDomain Code=3 "(null)" [SKTestSession] Error clearing overrides: Error Domain=SKInternalErrorDomain Code=3 "(null)" [SKTestSession] Error setting value to 1 for identifier 2 for jp.unext.mediaplayer: Error Domain=SKInternalErrorDomain Code=3 "(null)" And the simulator asks me to provide my AppleID. Tests have been broken since at least 26.4 The release notes claims that it has been fixed but not for me. https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-26_5-release-notes#StoreKit-Testing-in-Xcode Does anyone else have the same issue? Reported FB22774836 just in case.

In previous versions of Simulator.app, you could drag an unsigned iOS .app bundle onto the Simulator screen to install it. This was useful functionality to allow for more easy distribution of simulator-only builds within a team without needing to worry about signing and distribution. This functionality appears to have been completely removed in Device Hub which is a shame.

在使用 xode 27 真机调试项目时 报了 ibrary 'd64' not found 这个错误， 这边有用到-ld64 遇到这个问题需要怎么去解决呢？ xcode 26 没有报这个错

Since the XCode 27 came out with the device hub, I can't found the option "External Display"! This is outrageous, since I have an app that only works with a external display connected! This menu existed on the menu bar of the simulators, but since the simulators was replaced by the device hub, I can't debug or test my app anymore!

Xcode / Claude Agent says "Approve the plan using the Exit Plan button when you're ready, and I'll start building." There is no Exit Plan button. How do I approve the plan?

Is anyone else having issues uploading an archive to App Store Connect? I went to validate an archive of my app, and seems to hang during validation. I've tried just validating the app, and tried Transporter as well. It hangs on the analyzing app. How to troubleshoot?

Environment: Xcode 27.0 beta 6, Device Hub, tvOS 27.0 When focusing a TextField and using Device Hub to run on tvOS 27.0, I cannot type any text into the field. Focus moves to the TextField as expected, but keyboard input is not received. Has anyone else run into this? Any workaround would be appreciated.

I have been trying for 24 hours to upload app, and first time this has happened in 8 years and 100+ uploads. Please help. Validate App and Upload both hang indefinitely at "Preparing" in Xcode Organizer. No error is ever returned — the progress bar freezes and the operation never completes or times out. Transporter 1.4.5 fails identically. Key detail: archive 2.4.3 (build 123), which Apple accepted and processed on Sept 10, 2026, now hangs the same way when validated. Same machine, same Xcode, same Apple ID. This rules out the archive, its signature, and its provisioning profile. Already ruled out: two independent networks (home Wi-Fi and iPhone cellular hotspot); the archive itself (known-good build 123 fails identically); Xcode install (27.0 / 27A266a, xcode-select verified correct); Apple ID session (signed out and back in three times); full reboot. macOS 27.0 (26A428) on MacBookPro18,4. Last successful upload Sept 10, 2026. 100+ prior archives uploaded without incident over several years. macOS has updated twice since Sept 10. Separately: Transporter 1.4.5 crashes on macOS 27.0 with an unhandled exception in TransporterKit while drawing its activity queue (EXC_BREAKPOINT via +[NSApplication _crashOnException:]).

Xcode 27.0, watchOS 27.2, macOS 27.2. Re-pairing an Apple Watch Ultra 2 via Device Hub (File ▸ Pair Nearby Device…) completes successfully — remotepairingd logs setupManualPairing succeeded — but the watch never reconnects afterward: no verifyManualPairing, no _remotepairing._tcp Bonjour advertisement, and CoreDevice never creates a device record for it. devicectl shows the watch as unavailable, then it disappears from the list entirely. Compare: pairing an iPhone the same way also closes the setup channel within ~40 ms, but the iPhone reconnects ~1.3 s later via verifyManualPairing and becomes available. The watch never does. Interesting finding: if the Mac's pairing listener is kept open past the point where Device Hub's sheet would normally close it, the watch does come back — but it requests a brand-new pair-setup instead of verifying the one it just completed. It loops: setup → close → setup. Already tried without success: restarting the watch/iPhone, Developer Mode off/on, Bluetooth on/off, Wi-Fi toggles, iPhone on USB, restarting CoreDeviceService and remotepairingd, Reset Location & Privacy on the iPhone, updating watchOS (27.0 → 27.2, same behavior). Full write-up with sanitized logs, timeline and everything tried: https://github.com/kisnner26/watchos27-pairing-bug Filed as Feedback Assistant FB24924229. If anyone else hits this exact symptom (pairing succeeds, watch never reconnects — different from the PIN never appearing, or the watch never showing up at all, which are other variants reported elsewhere), please share your report ID here so Apple can link them.

[Submitted as FB24979057] Device Hub is consistently crashing for me in Xcode 27.1. I initially encountered it while working in Xcode, but I can reproduce it completely independently of any project: Quit Xcode. Launch Device Hub directly. Wait a couple of seconds. Device Hub crashes. The latest crash occurred about two seconds after Device Hub launched, so this doesn’t appear to be related to a particular Xcode project. :chatgpt-content-reference{index="0"} Environment Xcode 27.0 (27A266a) DeviceHub 27.0 (255.2.6.6) macOS 27.0.1 (26A434) Apple silicon The crash is on the main thread during AppKit/SwiftUI layout and constraint updating: :chatgpt-content-reference{index="1"} :chatgpt-content-reference{index="2"} Exception Type: EXC_CRASH (SIGABRT) Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6 AppKit -[NSWindow(NSDisplayCycle) _postWindowNeedsUpdateConstraints] -[NSView setNeedsUpdateConstraints:] SwiftUI NSHostingView.setNeedsUpdate() NSHostingView.beginTransaction() AppKitPlatformViewHost.invalidateLayout() NSHostingView.SizeConstraints.update(from:) DeviceHub main Has anyone else seen this in Xcode 27.1 or found a workaround?

I have raised Feedback FB23036084 Just using it on an extremely small app that display six SwiftUI charts. I was just scrolling on a ScrollView of the charts. Th feedback has a link to the app on GitHub, the content of the generate report details and also the output of running xcrun simctl diagnose

Apple M2 MacBook Pro 2022 (24GB/1TB) macOS 27.0 Xcode 27.0 Xcode hangs every time I try to open any xib file. Didn't face this issue in previous versions. I have attached some initial part of the report here, I have reported the problem via xcode too. Xcode hang.txt

what can i do?

I wanted to test my App for Apple TV and iPad/iPhone with a DualShock 2 game controller. This worked perfect with the former Xcode version. Now nothing happens, if I use the game controller. In blue tooth is is connected and if I use my game without Device Hub it is also working. Additionally it is nearly impossible to debug my game on Apple Watch with the Digital Crown, it takes minutes to start the simulators for iPhone, my Mac is getting extremely hot, ... Is there a possibility to use the old simulator? Device Hub is not really usable for developers.

Hi everyone, Is anyone else having problems with Xcode 27? It keeps crashing on me. And when I say ‘constantly’, I mean it shuts down about every minute. You can’t work like this... Am I the only one with this problem?

I have two apps; one is a subset of functionality of the other. The smaller app has about 170 Swift files. The larger app has these files plus about 120 more. So I would expect the larger app to take around twice as long to build. Instead, the smaller app takes less than a minute to build while the larger app takes over 13 minutes to build; to be exact, it takes 15.3 times longer. While reviewing the build report, I noticed that the smaller app compiles the Swift files in batches, with each batch taking around 10 seconds, but with up to 17 batches running at once. In contrast, the larger app compiles all 290 Swift files in one giant batch, so apparently there is no multithreading of the Swift compilation (see screen shots below). The difference in the number of batches the smaller app compiles at once roughly corresponds to the difference in overall build time. Is there a build setting I can change to make the larger app compile Swift files in multiple smaller batches as the smaller app is doing? I checked SWIFT_COMPILATION_MODE and it's the same in both apps (Incremental for debugging and Whole Module for release) but I don't know what other settings I should check.