Open Activity Monitor while Xcode is running and you will find it near the top of the memory list, often alongside the Simulator process sitting just beneath it. A freshly opened project might show 2-3 GB. Start a build, open a Preview canvas, and run the Simulator at the same time, and the combined total can reach 10 GB or more. For a single developer tool, that is a significant claim on available RAM.
It makes sense once you understand what Xcode is actually doing. It is not one process with one job. It is a host for several large, independent subsystems that each have their own appetite for memory, and which often run simultaneously.
Where Xcode's memory goes
Xcode's memory footprint comes from four distinct sources, and understanding each one separately makes the numbers easier to reason about.
sourcekit-lsp is the language server that powers Xcode's code intelligence. It parses your Swift and Objective-C source, resolves types, tracks symbol references, and answers queries as you type - completions, jump-to-definition, inline diagnostics. To do this quickly, it keeps a substantial representation of your project in memory at all times. The cost scales with project size: a small app might add 300-600 MB, a large codebase with many dependencies can push sourcekit-lsp above 1 GB on its own.
Indexing is a related but separate process. When you open a project or make changes, Xcode's background indexer builds and maintains a full symbol database on disk, used for features like Find Symbol and refactoring tools. During an initial index or a re-index after a large merge, the indexer can spike memory noticeably. The com.apple.dt.SKAgent and related helper processes are what you'll see in Activity Monitor during these bursts.
SwiftUI Previews are the most variable contributor. Each preview canvas spawns a PreviewsAgent process that compiles a preview-specific build of your module and renders it. If your view imports a large dependency graph, that compilation is not lightweight. A single active preview canvas typically adds 500 MB to 1.5 GB on top of everything else. Multiple canvases multiply that figure.
Simulators are virtual devices. Each running Simulator - an iPhone, an iPad, an Apple Watch - is a complete virtual operating system instance. A running iOS Simulator typically uses 500 MB to 1 GB of RAM on its own, not counting the app you've installed inside it. Running two Simulators simultaneously for device comparison adds that cost twice.
Realistic numbers across project size and build state
The range of what Xcode uses is wide, because the answer depends heavily on what you're doing at any given moment. Here is a practical breakdown:
- Small project, idle (no build, no previews, no Simulator): 1.5-3 GB. sourcekit-lsp is running, the index is loaded, and Xcode itself is open. This is the floor.
- Mid-size project, idle: 2.5-4 GB. The larger symbol graph and index push the baseline up.
- During a clean build, mid-size project: 5-8 GB. The Swift compiler allocates heavily as it processes each target. Memory spikes during compilation and returns toward baseline when the build finishes.
- With one SwiftUI Preview active: add 500 MB to 1.5 GB to whichever baseline applies.
- With a Simulator running: add 500 MB to 1 GB per running device.
- Large workspace with multiple targets, Previews, and a Simulator: 10-14 GB combined is not unusual. This is the scenario that makes 16 GB feel tight.
The best way to see your actual numbers is Activity Monitor (Command-Space, type "Activity Monitor", press Return). Click the Memory tab and look at the processes individually: Xcode, com.apple.dt.SKAgent, PreviewsAgent, and any Simulator entries all appear separately. The Memory Pressure graph at the bottom tells you whether the combined total is straining your system. For a deeper explanation of what that graph means, see what memory pressure means on Mac.
The SwiftUI Preview memory bomb (and how to manage it)
SwiftUI Previews are the feature most likely to surprise developers with unexpected memory consumption. The experience is familiar: you open a view file, enable the Preview canvas, and within moments your Mac's fans spin up and Activity Monitor shows a new PreviewsAgent process consuming 800 MB that wasn't there before.
The reason is that generating a preview is not a simple render. Xcode compiles a separate, preview-optimised build of your module - one that can inject mock data and update live as you edit. If that module imports a large framework or has many dependencies, the compilation is substantial. Each file you have a preview open for creates its own agent process.
Practical ways to manage SwiftUI Preview memory:
Disable the canvas globally and enable it only when you need it. In Xcode's Editor menu, "Canvas" toggles the Preview pane. Closing it when you're not actively iterating on a view stops the PreviewsAgent from running at all for that file. This is the highest-impact single action for Previews-related memory.
Keep your preview dependencies shallow. If a view's preview requires initialising large objects or injecting complex environment dependencies, move as much of that complexity into a lightweight PreviewProvider struct. A preview that only needs a small piece of mock data will compile and run with far less memory than one that instantiates your entire app's data layer.
Use #Preview macros selectively. The Swift macro-based previews introduced in Xcode 15 are more efficient, but every file with a #Preview block will have its canvas compiled when you open that file. If you have previews in dozens of files, Xcode will happily try to build all of them. Prune preview declarations from files you're not actively working on.
Apple's documentation on previewing your app's interface in Xcode covers the architecture and best practices in more detail, including how to structure previews for complex views.
The Simulator question (per-device cost, when to quit them)
Each Simulator you have running is a full virtual device. That means a kernel, a system process tree, and whatever apps are installed - all resident in memory. The per-device cost varies by the device type being simulated:
- iPhone Simulator: typically 500 MB to 900 MB for the Simulator runtime itself, plus the memory used by the app under development.
- iPad Simulator: similar to iPhone, sometimes slightly higher due to larger screen resolution and different memory management characteristics.
- Apple Watch Simulator: lower, typically 300-500 MB, but rarely used in isolation.
- macOS target (running natively): no Simulator overhead, but your app's own footprint is counted directly.
The practical question is when to quit Simulators. The answer is: as soon as you've finished the test run you needed them for. A Simulator sitting idle at the home screen is still holding its full runtime in memory. Quitting it via the Simulator's menu (Simulator - Quit Simulator) or from the command line with xcrun simctl shutdown all frees that memory immediately. If you regularly leave multiple Simulators running between sessions, this is one of the most straightforward places to reclaim memory without affecting your workflow.
If you need to compare layouts across devices, consider running one Simulator at a time and using Xcode's canvas size variants rather than two simultaneous instances. For broader context on how 8 GB and 16 GB Macs handle developer workloads, see 8 GB vs 16 GB Mac: which one do you actually need.
Practical fixes
These are the actions with the highest-to-lowest ratio of memory recovered versus effort required.
Reduce active previews. As described above, closing the Preview canvas when you're not using it is the single highest-impact change for most developers. Enabling it per file, rather than leaving it open across your whole project, prevents Xcode from running PreviewsAgent instances you're not looking at.
Prune Derived Data. Xcode's DerivedData folder stores build artifacts, index databases, and module caches. It can grow to 30-50 GB and Xcode sometimes loads stale index data from it into memory. Clear it from Xcode Settings - Locations - Derived Data, or run rm -rf ~/Library/Developer/Xcode/DerivedData in Terminal. Xcode rebuilds what it needs on next launch. Worth doing every few months, or after major Swift or Xcode version changes.
Restart Xcode on a schedule. Xcode's memory grows over long sessions: sourcekit-lsp accumulates state, orphaned indexer processes linger, and compiler helpers stay resident after builds. Quitting and relaunching once a day resets all of this and consistently returns several gigabytes. If Xcode feels sluggish by mid-afternoon, a restart is the fastest first step.
Quit Simulators when not actively testing. Each idle Simulator holds its full runtime in memory. Quitting immediately after a test run prevents gradual accumulation across a day of development.
For context on how Xcode fits alongside other memory-intensive tools, the post on Figma on Mac: memory usage explained covers a tool that often runs alongside Xcode with its own significant footprint. To understand your Mac's overall memory situation, see what memory pressure means on Mac.