Xcode 26.4 silently broke Interface Builder for Objective-C projects. Xcode 26 crashes with EXC_BAD_ACCESS the moment you launch onto an iOS 27 beta device. Xcode 27’s new Coding Assistant opens conversations in a floating window instead of next to your code. And nobody’s Mac can delete the 9–85 GB of orphaned simulator runtime sitting under /System/Library/AssetsV2/. The IDE itself has become the bug, and the workarounds are not in the release notes.

This is a working developer’s reference for four current Xcode regressions and the exact steps to get past each one.

Xcode 26.4 / 26.5: IBOutlet gutter circles missing in Objective-C projects

If you opened a storyboard in Xcode 26.4 and noticed the small gutter circles next to your IBOutlet and IBAction declarations are gone, you are not imagining it. The drag-from-source-to-canvas workflow that has worked since Xcode 4 no longer renders the connection affordance in Objective-C source files. Existing connections still work at runtime; you just cannot make new ones the usual way.

The issue is tracked under FB22658201, FB22437928, and FB22903154 in thread 820868, with 24+ participants confirming. Xcode 26.5 did not fix it. Swift projects are less affected.

What to do

Two paths get you working again.

Option A: downgrade to Xcode 26.3. It is the last known stable release for Objective-C IB work. Keep it in /Applications/Xcode-26.3.app, use xcode-select to switch when you need it:

sudo xcode-select -s /Applications/Xcode-26.3.app/Contents/Developer
xcodebuild -version

Option B: make connections via the Connections Inspector. If you must stay on 26.4+, you can still wire things up, just not by dragging from gutter to canvas:

1. Declare the outlet or action manually in your .h file:

   @property (weak, nonatomic) IBOutlet UILabel *titleLabel;
   – (IBAction)doneTapped:(id)sender;

2. In Interface Builder, right-click your UI element, then drag from New Referencing Outlet (or New Referencing Action) to File’s Owner in the Placeholders bar.

3. Pick the property name from the popup.

This is slower but reliable. I use Option A on my Objective-C maintenance projects and Option B on Swift projects where the gutter glitch is intermittent rather than total.

Xcode 26 crashes apps on iOS 27 / visionOS 27 beta devices

If you tried to debug your app on an iOS 27 beta 2 device using Xcode 26 and got EXC_BAD_ACCESS at launch, that is documented in thread 836048. DTS’s official line is “using Xcode 26 to run apps on appleOS 27 beta is not supported.” That’s true, and also not the whole answer — there is a hidden scheme setting that causes the crash and lets you keep working if you turn it off.

The fix

The culprit is Enable backtrace recording under Queue Debugging:

1. Product → Scheme → Edit Scheme…
2. Select Run in the sidebar.
3. Go to the Options tab.
4. Under Queue Debugging, uncheck Enable backtrace recording.

Re-run. The crash on launch is gone. You still cannot expect a fully supported debugging experience against an OS that is one generation ahead of your Xcode, but routine launch-and-test works.

For real beta-OS testing, Apple’s supported path is to install your app from TestFlight or sideload an exported .ipa to the beta device, and to use Xcode 27 (which is co-developed with iOS 27) for live debugging.

Xcode 27 Coding Assistant: open conversations in the editor pane

Xcode 27 ships a Coding Assistant pane. The default behavior — clicking New Conversation in the toolbar — opens the conversation in a floating window detached from your project window. If you liked Xcode 26’s side-by-side layout, thread 833605 has the hidden right-click that restores it.

The fix

1. Start a new conversation any way you like.
2. Open the Coding Assistant tab in the navigator.
3. Right-click the conversation you want to use.
4. Choose Open in Editor Pane.

The conversation now docks next to your source files. You can also set the default in Xcode → Settings → Navigation to Open in Editor Pane (or Destination Chooser if you want a per-click prompt). Apple feedback FB23258229 asks for this to be the out-of-the-box default.

A minor warning: the assignment is fragile. Hitting the toolbar button rather than right-clicking the conversation sometimes pops it back out into a floating window. I have stopped using the toolbar button entirely.

Orphaned simulator runtimes: 9–85 GB you can’t delete

Run xcrun simctl runtime list after a year of Xcode upgrades and you will probably see entries that no longer correspond to any installed simulator. Some of these are bona fide orphans living under /System/Library/AssetsV2/, in SIP-protected territory. xcrun simctl runtime delete does not touch them, rm -rf returns “Operation not permitted,” and tools like DevCleaner cannot help.

In thread 812992, Quinn “The Eskimo!” confirms it is a bug in Apple’s runtime asset lifecycle management and that there is no supported cleanup path. The unsupported one involves disabling SIP via Recovery Mode.

What I actually do

Before reaching for SIP, exhaust the supported tools. They clean a surprising amount:

# List everything Xcode thinks is installed.
xcrun simctl runtime list -v

# Delete by identifier — works for runtimes Xcode still tracks.
xcrun simctl runtime delete <identifier>

# Wipe all device data, often a bigger win than chasing runtimes.
xcrun simctl delete unavailable
xcrun simctl erase all

# Clear DerivedData while you are at it.
rm -rf ~/Library/Developer/Xcode/DerivedData/*

If xcrun simctl runtime list still shows runtimes Xcode can no longer launch, and your free space is genuinely a problem, the workaround documented by multiple forum participants is:

1. Boot into Recovery (hold the power button on Apple silicon; Cmd+R on Intel).
2. Utilities → Terminal, then csrutil disable.
3. Reboot to macOS, identify the orphaned folder under /System/Library/AssetsV2/, and sudo rm -rf it.
4. Boot back into Recovery and csrutil enable.

I do this once a year at most, and only on a development Mac with a fresh Time Machine backup. Quinn is right that it is unsupported. He is also right that the better fix is to file an FB with the orphan’s identifier so Apple can address the underlying leak — every forum participant who skipped that step is part of why this has not been fixed yet.

A working setup that keeps Xcode from being the bug

A few habits help:

• Keep two Xcode versions installed. I have Xcode 26.3 (for Objective-C / storyboards), Xcode 27.x (for current iOS), and switch with xcode-select. Move each into /Applications/Xcode-<version>.app.
• Never run a beta OS on your only test device. The forum threads on charging regressions and toolchain mismatches are full of “this is my only iPhone” stories. Buy a secondhand device, or stay on stable.
• Snapshot ~/Library/Developer/CoreSimulator size monthly. When it grows by tens of gigabytes between releases, run xcrun simctl delete unavailable before it becomes the SIP problem above.
• File FBs with reproductions. Quinn’s point holds: bugs without numbers do not get fixed. Capture the exact Xcode build number, the runtime identifier, and a sysdiagnose where relevant.

Next steps

Xcode regressions usually arrive alongside SDK changes — UIDesignRequiresCompatibility, size-class behavior, Reality Composer Pro project format. If you are planning a beta-OS run, line up the toolchain workarounds first, then the SDK ones.

---