Fix Xcode 26 Simulator Slowness & Crashes (2026)

If you upgraded to Xcode 26 or 26.1 and your iOS Simulator suddenly boots in two minutes, lags while typing, spins your fans up, or just crashes the app the moment LLDB attaches, you are not doing anything wrong. Xcode 26 shipped with several distinct simulator regressions, and Xcode 26.1 added a particularly nasty new one that almost nobody has consolidated in one place yet.

This is a runbook. Each fix below is its own section, ordered by how likely it is to be your problem. (If the local Simulator stays unusable and you just need to run a build today, an online iPhone simulator that streams from a remote Mac is a viable stopgap while you work through these.) Start at the top, verify after each step, and stop when the symptom is gone. The single highest-probability fix on 26.1 is the wallpaper trick in the first section — try it before anything else.

Why are Xcode 26 simulators slow or crashing?

There is no single root cause. Xcode 26's simulator problems are a stack of separate regressions, and which one is hitting you depends on your exact version and setup:

The 26.1 ReportCrash bug is the new one. Per the Apple Developer Forums and a widely-referenced Apple Community thread, the iOS 26.1 simulator runtimes ship without their default wallpaper assets. The process that loads the simulator's background image (MercuryPosterExtension) crashes when it can't find one, macOS spawns ReportCrash to capture the crash, the extension immediately relaunches and crashes again, and you get an infinite crash-report loop that saturates one or more CPU cores. Developers have filed feedback reports for this (community-reported IDs include FB20918609 and FB20925624).

How do I fix the Xcode 26.1 ReportCrash high-CPU bug?

This is the section to read if your Mac runs hot and the fans are loud whenever a 26.1 simulator is open, even with no app running. Confirm it first, then apply the cheapest fix that works.

Confirm it's this bug. Open Activity Monitor, sort by % CPU, and look for a ReportCrash process burning 60-160% CPU while an iOS 26.1 simulator is booted. You may also see MercuryPosterExtension appearing and disappearing repeatedly. If you don't see ReportCrash high, this isn't your problem — skip to the slow-boot section.

Fix 1 (fastest, recommended): set a wallpaper in the simulator. This addresses the root cause directly by giving MercuryPosterExtension the asset it's looking for.

1. Boot the affected iOS 26.1 simulator.
2. Inside the simulator, open Settings.
3. Go to Wallpaper and choose any wallpaper, then set it for both the lock and home screens.
4. Watch Activity Monitor: ReportCrash CPU should drop to ~0% within a few seconds.

You have to do this once per affected simulator device. It survives reboots of that device because the wallpaper choice is persisted in the device's data.

Fix 2: use the iOS 26.0.1 simulator runtime under Xcode 26.1. Multiple developers report that installing and targeting the older iOS 26.0.1 runtime inside Xcode 26.1 does not engage the ReportCrash loop at all (community-reported). Install it via Xcode > Settings > Components (the same panel covered in our iOS Simulator setup guide for Mac), then point your scheme's run destination at a 26.0.1 device. Good if you can't change app behaviour with a different OS or just want it gone without touching every simulator.

Fix 3 (blunt instrument): disable the crash reporter. If you can't set a wallpaper for some reason, you can stop macOS from spawning the crash reporter at all. Omit the -w flag so the change is not permanent and the services come back on next reboot:

launchctl unload /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

This is a workaround, not a fix: the underlying extension is still crash-looping (wasting some CPU), you've just muted the report-generation overhead, and you've globally disabled crash reporting for your whole Mac. Re-enable it with launchctl load on the same paths, or just reboot. Prefer Fix 1 or 2.

Fix 4: update Xcode. Apple shipped Xcode 26.1.1 on top of 26.1. Its published release notes do not explicitly call out a ReportCrash fix, and at least one independent analysis (Michael Tsai's blog) suggests the only substantive new item in 26.1.1 is a coding-intelligence performance change rather than a simulator fix. Treat "upgrade to 26.1.1" as worth trying but unconfirmed for this specific bug; the wallpaper fix is the reliable one regardless of Xcode point release.

Why does my app take minutes to launch in the simulator?

Separate problem. If the simulator boots fine and your Mac isn't hot, but pressing Run takes 1-5 minutes (commonly ~2 minutes) before your app appears and console output starts, this is the LLDB-attach / dyld-cache slowdown reported across multiple Apple forum threads on Xcode 26.x.

Fix 1: make sure the dyld shared cache is fully generated. Apple's guidance is that overall slowness can be the system still building the simulator runtime's shared cache in the background. Force it to complete up front:

xcrun simctl runtime dyld_shared_cache update --all

Let it finish (it can take several minutes the first time per runtime). Subsequent launches should be dramatically faster. This is also the right fix for "the first launch of a freshly-installed runtime is unbearably slow" — that's the one-time cache build, and this command front-loads it instead of paying it on first Run.

Fix 2: temporarily disable Debug Executable. This is the most-reported workaround for the slow Run on Xcode 26.x. With it off, Xcode launches the app without attaching LLDB, which sidesteps the attach overhead entirely:

1. Product menu > Scheme > Edit Scheme (or ⌘<).
2. Select Run in the left column.
3. On the Info tab, uncheck Debug executable.
4. Close and Run again.

The trade-off is real: with Debug Executable off you lose breakpoints, the variable inspector, and the LLDB console for that run. Use this for fast iteration on UI/layout work where you don't need the debugger, and re-enable it when you actually need to step through code. It is a workaround for the regression, not a setting you should leave off permanently.

Fix 3: turn off heavy diagnostics for routine runs. Address/Thread/Undefined-Behavior sanitizers, Malloc Scribble/Guard, Zombie Objects, and Malloc Stack logging all add significant launch and runtime overhead, and Apple support has pointed at these as compounding factors. Edit Scheme > Run > Diagnostics and switch them off for everyday runs; re-enable per-investigation.

Why does lldb-rpc-server keep crashing or hanging on "Attaching"?

If Xcode sits on "Attaching to <app>" forever, or you get "Xcode has killed the lldb-rpc-server", that's the debugger transport regression discussed in the Xcode 26 debugging community writeups and several Apple forum threads. Work through these in order:

1. Fully quit the Simulator (Simulator menu > Quit, not just close the window), quit Xcode, relaunch both. A stale simulator process is the most common cause of the "Attaching" hang.
2. Disconnect any physical iPhone. If CoreDevice is stuck talking to a connected device, it can block the simulator path. Unplug the device and retry the simulator.
3. Kill stuck debugserver/lldb processes: killall -9 lldb-rpc-server debugserver then Run again.
4. Erase the simulator (next section) if the device itself is in a bad state.
5. Last resort: disable Debug Executable (previous section) to confirm the app itself is fine and isolate the problem to the debugger.

How do I erase and reset a broken simulator?

A simulator device whose data directory is corrupt will be slow or crash no matter what else you do. Erasing returns it to a clean state. This destroys all installed apps and data on that simulator, so it's safe for dev work but don't do it on a device you've hand-configured for a demo.

From the Simulator UI: with the device booted, Device menu > Erase All Content and Settings.

From the command line (all devices at once):

# erase a single device by name or UDID
xcrun simctl erase "iPhone 17 Pro"

# nuclear option: erase every simulator
xcrun simctl shutdown all
xcrun simctl erase all

Note that erasing wipes the wallpaper you set for the 26.1 ReportCrash fix, so if you erase a 26.1 device you'll need to redo the wallpaper step afterward.

Does clearing derived data and caches actually help?

It helps when the slowness is build-side rather than simulator-side (long incremental builds, stale modules, indexing thrash), and it's cheap to try. It will not fix the 26.1 ReportCrash CPU bug or the LLDB-attach delay, so don't reach for it first.

# nuke DerivedData (Xcode rebuilds it on next build)
rm -rf ~/Library/Developer/Xcode/DerivedData

# Xcode's own cache
rm -rf ~/Library/Caches/com.apple.dt.Xcode

# old on-device symbol caches (large, safe to remove)
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

You can also do this from the GUI: Xcode > Settings > Locations, click the arrow next to Derived Data, and delete the folder. Expect the next build to be slow (full rebuild) and then back to normal.

Is low disk space or Rosetta making my simulator slow?

Two environmental factors worth ruling out before you blame Xcode:

Disk space. Simulator runtimes, DerivedData, and device-support archives are large. When the boot volume gets tight, the simulator and the dyld_shared_cache generation slow to a crawl. Keep several tens of GB free; clear DerivedData and unused runtimes (Xcode > Settings > Components) if you're low.

Rosetta / x86_64 simulators on Apple Silicon. If your app depends on x86_64-only frameworks and you're running an Intel-architecture simulator under Rosetta, expect debugger freezes on "step over" and an unresponsive app, as reported on the Apple Developer Forums. The durable fix is to update those dependencies to ship an arm64 simulator slice so you can run the native simulator. As a stopgap, fully quit the simulator and rebuild, which sometimes clears the freeze temporarily (community-reported) — or offload that test run to a cloud-backed browser-based iOS simulator (Xcode 26, TestMu AI, Corellium) while you sort out the architecture mismatch locally.

How do I verify the fix actually worked?

Don't trust "it feels faster". Verify against the specific symptom:

• ReportCrash bug: open Activity Monitor, sort by % CPU, boot the 26.1 simulator, and confirm ReportCrash stays at ~0% and MercuryPosterExtension isn't churning. Touch your Mac's chassis after 5 minutes idle with the sim open; it should be cool and the fans quiet.
• Slow launch: time from pressing Run to first console output. After dyld_shared_cache update --all and/or disabling Debug Executable it should be seconds, not minutes.
• LLDB hang: set a breakpoint, Run, and confirm it actually attaches and hits the breakpoint instead of sitting on "Attaching".

If the symptom persists after the targeted fix, you're likely on a different cause from the table at the top - go back and match symptom to cause again rather than stacking unrelated fixes.

When should I file feedback or downgrade Xcode?

File Feedback (Feedback Assistant) if you hit the ReportCrash loop or the LLDB hang and the workarounds above don't hold. These are confirmed regressions Apple is tracking (community-reported feedback IDs FB20918609 / FB20925624 for the ReportCrash issue); adding a duplicate with a sysdiagnose attached raises the priority. Include your exact Xcode build, the simulator runtime version, and a screen recording of Activity Monitor.

Downgrade Xcode only as a last resort, and prefer the lighter alternatives first:

1. Use the iOS 26.0.1 runtime under your current Xcode (sidesteps the ReportCrash bug without a full downgrade).
2. Keep a second Xcode version side-by-side (rename the app, e.g. Xcode-26.0.app) and switch with xcode-select -s for the projects that need it.
3. Only do a full downgrade if a hard regression blocks shipping and no runtime swap helps. Archive builds and CI signing requirements often pin you to a minimum Xcode, so check those constraints before rolling back. If a regression is genuinely blocking and you need a working iOS environment now, our roundup of iOS emulators and simulators for Mac covers Corellium and Appetize as alternatives that don't depend on your local Xcode at all.

FAQ

Why is my Mac hot and loud when the Xcode 26.1 simulator is open?

Almost certainly the iOS 26.1 ReportCrash bug. The 26.1 simulator runtime ships without a default wallpaper, which crash-loops MercuryPosterExtension and pins ReportCrash at 60-160% CPU. Open the simulator's Settings, set any wallpaper, and the loop stops within seconds. Confirm in Activity Monitor that ReportCrash drops to ~0%.

Does the wallpaper fix survive a restart?

Yes for that simulator device - the wallpaper choice is stored in the device's data and persists across simulator and Mac reboots. It does not survive "Erase All Content and Settings" on that device, and it has to be set per device, so if you create a new 26.1 simulator you'll need to set a wallpaper on it too.

Will disabling Debug Executable break my debugging?

For that run, yes - with Debug Executable off there are no breakpoints, no variable inspector, and no LLDB console because Xcode launches the app without attaching the debugger. That's exactly why launch is fast. Use it for UI iteration where you don't need the debugger and re-enable it when you need to step through code. It's a workaround for the Xcode 26 attach regression, not a permanent setting.

Did Xcode 26.1.1 fix the ReportCrash simulator bug?

Unconfirmed. Apple's 26.1.1 release notes don't explicitly list a ReportCrash simulator fix, and independent analysis suggests the main change was a coding-intelligence performance tweak rather than a simulator fix. Update anyway (it's low-risk), but rely on the wallpaper fix or the iOS 26.0.1 runtime for a result you can actually verify.

My first simulator boot after installing a runtime is extremely slow - is that normal?

Yes. The first boot of a freshly-installed runtime pays a one-time dyld_shared_cache generation cost, which can take several minutes. Front-load it with xcrun simctl runtime dyld_shared_cache update --all so you pay it once on your terms instead of on your next Run. Subsequent boots of that runtime should be fast.

I tried everything and the simulator is still slow - what now?

Re-match symptom to cause using the table at the top instead of stacking fixes. Confirm in Activity Monitor whether it's the ReportCrash loop (hot/loud), the LLDB-attach delay (slow Run, normal idle), or a Rosetta/disk-space environmental issue. Then file a Feedback Assistant report with your Xcode build, runtime version, a sysdiagnose, and an Activity Monitor recording so Apple can prioritize it.

Is it safe to disable ReportCrash on my Mac?

It's safe but blunt, and it's the last resort, not the first. Unloading ReportCrash without the -w flag is non-permanent (it returns on reboot), but while it's off you have no crash reporting for any app on your Mac, and the underlying extension is still crash-looping and wasting some CPU. The wallpaper fix removes the root cause; prefer it.

If your team is shipping iOS apps and losing hours to tooling regressions like these, having engineers who already know where the bodies are buried in the Apple toolchain pays for itself fast. Codersera matches you with vetted remote developers experienced with iOS, Xcode, and the simulator/CI stack, with a risk-free trial so you can validate technical fit before you commit.