Mac Slow With Xcode Open? Here's What's Going On

If you’ve ever opened Xcode for the first time in a few weeks and watched your fans spin up before you’ve even loaded a project, you know the feeling. Xcode is enormous. Apple’s IDE ships at over 14GB. It indexes your code, your dependencies, every framework header it can find. It runs the simulator, compiles Swift and Objective-C, links against thousands of files, and rebuilds previews live. All of that demands resources, and a Mac that handles ten Chrome tabs effortlessly can crawl the moment Xcode starts working.

Most Xcode slowness has identifiable causes. Some are about Xcode’s own caches and indexes. Others are about how your project is structured. A few are macOS-side issues that compound when Xcode is the heaviest app running.

What Xcode Is Doing in Activity Monitor

Open Activity Monitor while Xcode is running. You’ll see:

• Xcode — the editor and project window
• SourceKitService — provides code completion, syntax highlighting, semantic analysis
• swift-frontend — the Swift compiler (one process per file being compiled)
• clang — the C/Objective-C compiler
• lldb — the debugger, when you’re debugging
• Simulator (com.apple.CoreSimulator.CoreSimulatorService) — the iOS Simulator
• com.apple.dt.Xcode.sourcekit-service-helper — additional SourceKit workers

SourceKitService is often the surprise. It’s the process that powers code completion. On a large Swift project, it can use 5-10GB of RAM by itself. Worse, it sometimes gets into a state where it’s using 100% of a CPU core continuously, even when you’re not typing.

The fix when SourceKit goes rogue: in a terminal, killall SourceKitService. Xcode will relaunch it within seconds. This is a normal-enough occurrence that experienced developers have it as a muscle-memory shortcut.

Free up RAM in one clickSweep frees inactive memory and pauses runaway processes. Get Sweep free →

DerivedData: The Folder That Eats Your SSD

Xcode caches compiled output, indexes, and build intermediates in:

~/Library/Developer/Xcode/DerivedData/

This folder grows. Every project you’ve ever opened has a subfolder. Module caches, indexes, and intermediate object files pile up. On a developer Mac with a year of varied work, DerivedData can hit 50-200GB.

It’s safe to delete. Xcode regenerates everything it needs on next build. The trade-off is that the next build will be a full rebuild, not incremental.

Three ways to clean it:

1. Xcode menu > Settings > Locations > DerivedData — click the arrow to open in Finder, then move the contents to Trash
2. Terminal: rm -rf ~/Library/Developer/Xcode/DerivedData/*
3. Sweep — surfaces DerivedData specifically and shows total size before clearing

Beyond DerivedData, other Xcode-related folders to know:

• ~/Library/Caches/com.apple.dt.Xcode/ — additional caches
• ~/Library/Developer/CoreSimulator/Devices/ — every simulator device, with its own simulated drive (often 30-60GB combined)
• ~/Library/Developer/CoreSimulator/Caches/ — simulator caches
• ~/Library/Developer/Xcode/Archives/ — archived builds, can hit 50GB+

The Archives folder is particularly worth checking — every time you Archive for App Store submission, it adds an entry. Old archives for apps you no longer ship are pure waste.

Simulator: The Other Resource Hog

The iOS Simulator is essentially a virtualized iOS device running on macOS. It uses:

• 2-4GB of RAM for the simulator runtime
• 20-40GB of disk per simulator device (each simulated iPhone has its own simulated SSD)
• GPU resources for rendering
• CPU for ARM-to-x86 translation on Intel Macs (on Apple Silicon it’s native and much faster)

If you have multiple Xcode versions installed, each ships its own set of simulator runtimes. The sizes add up fast.

To clean up unused simulators:

1. Xcode > Settings > Platforms (in newer Xcode) or Xcode > Settings > Components (older)
2. Remove iOS versions you don’t need
3. In Terminal: xcrun simctl delete unavailable to remove orphaned simulators

For deeper cleanup: xcrun simctl erase all resets all simulators to factory state. They keep existing but their data is wiped.

Why Builds Get Slower Over Time

Xcode’s incremental build system is supposed to only recompile changed files. In practice, it gets confused. Common reasons:

1. Module timestamps drift — a clean build fixes this
2. Generated code from Storyboards or SwiftUI Previews triggers rebuilds
3. Code signing runs every build even on simulator
4. Swift Package Manager re-resolves dependencies more than necessary
5. Build phases run scripts that touch files Xcode then thinks have changed

To diagnose slow builds:

1. Product menu > Perform Action > Build With Timing Summary — shows which phases take the longest
2. Edit Scheme > Build > Show Build Timing Summary in Report Navigator — captures every build
3. Check the Build Settings > Other Swift Flags for -Xfrontend -warn-long-function-bodies=200 — this flags slow type-checks

Slow type-checks in Swift are notorious. Heavy use of generic code, ternary expressions, or type-inference-heavy SwiftUI views can make individual files take seconds to compile.

Indexing: Why Xcode Is Slow After Opening a Project

Xcode indexes every file in your project, every dependency, every framework header. On a large project, this is a one-time cost of 5-30 minutes after opening for the first time. Until indexing completes, code completion is partial and Jump to Definition may not work.

You can check index status: View > Navigators > Show Report Navigator. Look for an “Indexing” entry.

If indexing seems to never finish, or restarts repeatedly:

1. Quit Xcode
2. Delete DerivedData for the project (DerivedData > YourProjectName-randomstring)
3. Relaunch Xcode and let it re-index from scratch
4. If it still loops, file > swift package reset (for SPM projects)

Indexing eats CPU and disk while it runs. If your Mac feels slow for an hour after opening a project, indexing is probably why.

Skip the manual huntSweep finds the buildup slowing your Mac and clears it in seconds. Download Sweep free →

Settings That Help Xcode Run Faster

In Xcode > Settings:

• Source Control > General > Enable Source Control: OFF for non-Git projects — Xcode polls Git status constantly otherwise
• Components: remove old simulator runtimes
• Locations > Command Line Tools: ensure latest is selected

In your project’s Build Settings:

• Optimization Level: -Onone for Debug builds (default, but check)
• Compilation Mode: Incremental for Debug, Whole Module for Release
• Swift Compiler - Code Generation > Optimization Level: No Optimization for Debug
• Build Active Architecture Only: YES for Debug — only build for the architecture you’re running on

In Xcode preferences:

• Behaviors > Build Starts: don’t show navigators automatically — opening multiple panels mid-build slows the UI
• Text Editing > Display: turn off code folding ribbons if you don’t use them, slight UI gain

SwiftUI Previews: Their Own Performance Problem

If you’re using SwiftUI, previews are a huge resource sink. Each preview runs a small instance of your app in the simulator-like preview environment. Multiple previews in multiple files = multiple parallel preview processes.

Common preview slowness causes:

• Preview environment fails repeatedly and Xcode keeps retrying
• Heavy initializer code runs every preview refresh
• Sample data is too large
• Network calls fire during preview (use if ProcessInfo.processInfo.environment["XCODE_RUNNING_FOR_PREVIEWS"] == "1" to mock)

You can disable previews entirely: Editor > Canvas (Cmd+Option+Return) toggles it. When you’re not actively designing UI, keeping the canvas closed saves significant resources.

When Xcode Pegs Your Mac

If Xcode is making your Mac unusable:

1. Check Activity Monitor. Look for SourceKitService. If it’s at 100% CPU, killall SourceKitService in Terminal
2. Check swift-frontend processes. If many are running and pinned at 100%, a build is stuck. Stop the build (Cmd+.)
3. Force-quit Xcode if needed — it’ll restore your project state
4. Clean build folder (Product > Clean Build Folder, or Shift+Cmd+K)
5. Quit Simulator if it’s not actively in use
6. Close unused Xcode projects — each open project keeps SourceKit running for it
7. Restart your Mac — long uptime accumulates resources Xcode struggles to release

Pause runaway processes safelySweep identifies the apps actually eating your CPU and lets you pause them without losing work. Free for macOS →

Hardware Reality Check

Xcode is one of the few apps where hardware genuinely matters. Approximate guidelines for 2026:

• 8GB Mac — small Swift projects, simple Storyboards. Painful for anything serious
• 16GB Mac — medium projects, occasional simulator. The minimum for comfortable iOS dev
• 32GB Mac — large projects, multiple simulators, SwiftUI previews
• 64GB+ — heavy game dev, simultaneous Xcode + Photoshop/Final Cut workflows

Apple Silicon makes a bigger difference for Xcode than for most apps because Xcode does significant ARM-native work. A 16GB M2 will outperform a 32GB Intel Mac for Swift compilation.

Keeping Xcode Lean Over Time

Two habits that make a measurable difference:

1. Clean DerivedData monthly — saves disk, often resolves mysterious build issues
2. Delete unused simulator runtimes quarterly — Apple keeps adding new iOS versions; the old ones don’t auto-remove

Sweep can flag DerivedData and old simulator runtimes as part of its smart scan, so they don’t quietly grow until your SSD is full. Combined with Xcode’s own clean-up tools, that handles 90% of the long-term performance drift that makes a once-fast Xcode setup feel sluggish.

Xcode will always be heavy. The goal isn’t to make it light — it’s to make sure your Mac has the headroom to run it well, and that Xcode itself isn’t accumulating waste that compounds the problem.