Is macOS Swap Wearing Out My Apple Silicon SSD?

Swap Used is a live allocation gauge, not a wear odometer. The 2021 M1 scare started with startling device-write totals and borrowed TBW math, blamed swap — and left a habit of reading the gauge as the odometer. Here is how macOS memory actually works, what really spends SSD endurance, and how to measure whether swap matters on your Mac instead of arguing about it.

By CoreGuard · Jul 15, 2026 · 17 min read

Is macOS swap wearing out my Apple Silicon SSD?

No — not from the Swap Used number alone. That figure is occupancy, not an odometer; sustained swapping does generate real host writes, but you judge that contribution from the cumulative device-write trend, not from seeing a few gigabytes allocated at one moment.

The M1-era argument — and every thread it has spawned since — collapses three different measurements into one:

1. Swap Used — how much startup-disk space is currently occupied by swapped memory.
2. Cumulative host writes — how much data the host has sent to the SSD over time.
3. Physical NAND writes — what the controller actually programmed internally after garbage collection and write amplification.

Those numbers are related, but they are not interchangeable. If Swap Used says 4 GB, you do not know whether macOS wrote roughly that amount once and left it there, or churned far more data through the same allocation. You also do not know how much of the SSD’s lifetime write counter came from swap rather than apps, updates, caches, virtual machines, Spotlight, or ordinary filesystem work.

Swap is real I/O. It is worth observing. But “Swap Used is non-zero, therefore my SSD is being damaged” is not a measurement — it is a category error.

How macOS memory management actually works

A Mac using most of its RAM is not automatically short of memory. macOS tries to use memory efficiently, including for file caching, and the better live signal is Memory Pressure. Apple says the pressure graph is determined by the amount of free memory, the swap rate, and the amount of wired and file-cached memory — not by one crude “percent full” figure. Apple, “View memory usage in Activity Monitor”

When demand rises, macOS has several ways to make physical memory available. It can discard clean cached pages that can be read again from their original files. It can also compress inactive memory, storing the same logical contents in fewer RAM pages.

That second step matters here. In Activity Monitor, Compressed sits inside the memory breakdown, and Apple describes it as memory compressed to make more RAM available. Compression is CPU work in RAM — those pages are not written to the SSD merely because the Compressed number increased. Apple’s developer material draws the same line: the system may reduce the presence of long-unused dirty pages “by compressing these pages or storing them on flash or disk, which we call swapping,” and later it will “decompress or page in them.” Compressed and swapped are two different fates for a page. Apple’s WWDC22 game-memory session (10106)

If macOS still needs physical pages, it moves inactive memory to disk-backed swap. Apple describes virtual memory as temporarily moving data from RAM to disk when available RAM is limited, and macOS encrypts what it swaps. Apple, “What is secure virtual memory on Mac?”

The useful mental model is therefore:

memory demand → reclaim clean pages → compress inactive memory in RAM
             → swap pages to disk only when that is not enough

The real kernel policy is dynamic, not a literal conveyor belt every page traverses in that exact order. Compression and swapping can coexist. The important boundary is simpler: compressed memory is not the same thing as swapped memory, and only the disk-backed stage contributes swap writes.

Memory Pressure then tells you how well the whole arrangement is serving the workload. Apple’s reading of the colors: green means the Mac is using all of its RAM efficiently; yellow means it might eventually need more RAM; red means it needs more RAM. Apple, “Check if your Mac needs more RAM”

Non-zero swap alongside green pressure is not a contradiction. It can mean macOS moved cold pages out earlier and has no reason to bring them all back merely to make the Swap Used number look tidy.

What Swap Used measures — and what actually wears the SSD

Apple defines Swap Used as the amount of startup-disk space being used to swap unused files to and from RAM. That is an occupancy measurement. It answers one question: how much swap-backed storage is occupied right now?

It does not answer:

• How many bytes have ever passed through swap.
• How often the same swap capacity has been rewritten.
• How fast swap is currently writing.
• How much of the SSD’s cumulative write total came from swap.
• How many physical NAND bytes the controller programmed.

The Terminal view exposes the same kind of current state:

$ sysctl vm.swapusage
vm.swapusage: total = 3072.00M  used = 1218.50M  free = 1853.50M  (encrypted)

The values vary by Mac and by moment (on my Apple Silicon Mac, sitting at green pressure as I write this, all three read 0.00M). The fields are current total, used, and free swap capacity — not a lifetime total. The used value rises and falls as memory is swapped, reclaimed, or released, and it may stay non-zero long after the workload that caused the pressure has ended.

Think of it as a parking garage. “312 spaces occupied” does not tell you whether 312 cars entered today or 12,000 cars cycled through the same spaces. Swap Used is the occupied-space sign. It is not the turnstile counter.

What accumulates is the write traffic created when pages are sent to disk. Those writes land in the SSD controller’s Data Units Written counter alongside writes from every other source. On Macs where a current version of the free, open-source smartmontools can read the internal NVMe health log, the read-only command is:

smartctl -a disk0

The NVM Express specification defines Data Units Written as host data written to the controller, reported in thousands of 512-byte units and rounded up — one raw unit is 1,000 × 512 = 512,000 host bytes. NVM Express specification archive

That counter is one-way and cumulative. Swap Used is not.

There is one more boundary. Data Units Written is host traffic, not physical NAND traffic. The controller performs garbage collection, wear leveling, and data relocation below it. SNIA defines write amplification as NAND writes divided by host writes; without controller-specific telemetry, Data Units Written gives you the denominator, never the hidden physical total. SNIA, “Endurance of NVMe, SAS, and SATA SSDs”

Why the M1 and 8 GB panic misreads the gauge

The original concern was not invented from nothing — and it did not start with the Swap Used gauge. In early 2021, owners of the first M1 Macs reported startlingly high device-write readings via smartctl; one first-hand account measured about 50 TB written on a roughly 500 GB drive after two months, and aggressive swap was widely suspected as the driver. Peter Forret, “SSD wear on Apple Silicon M1” (2021) Lifespan projections borrowed from retail-SSD TBW ratings did the rest. Apple sold M1 MacBook Air configurations with 8 GB of unified memory and a 256 GB SSD (Apple, M1 Air specifications), so sustained memory pressure on those machines was a plausible suspect.

Sustained memory pressure on an 8 GB machine can create sustained swap writes. That part is physically ordinary: pages sent to disk are host writes, and flash endurance is finite.

What the episode left behind is a shortcut that outlived it:

My Mac shows 3 GB Swap Used, therefore it has just written 3 GB — or writes 3 GB continuously — and the SSD is being destroyed.

None of those conclusions follows from the allocation gauge.

Two Macs can both show 3 GB Swap Used. One populated that allocation during a short workload and has barely touched it since. The other is cycling pages in and out under continuing red pressure. Their current allocation is identical; their cumulative traffic is not.

The reverse mistake also happens. Zero Swap Used now does not prove the machine never swapped earlier. A current gauge cannot reconstruct past activity.

Nor does “8 GB” produce a universal answer. It can be adequate for one browser, mail, documents, and modest development work, yet inadequate for a workload combining large creative apps, virtual machines, containers, local models, and dozens of active browser processes. The useful question is not whether the Mac has ever used swap. It is whether persistent memory pressure is materially steepening this Mac’s device-write trend.

How to measure swap’s contribution to device writes

There is no Apple counter labeled “lifetime SSD bytes written by swap.” You have to join two evidence streams by time:

• Memory-side evidence: Memory Pressure, Compressed, Swap Used, and signs that swap activity is occurring.
• Device-side evidence: the change in Data Units Written across the same window.

Start with Activity Monitor’s Memory tab. Record Memory Pressure, Compressed, and Swap Used at the beginning and end of a recognizable workload window. A screenshot is useful context, but two readings are better: they show whether the allocation changed and whether pressure stayed green, moved through yellow, or sat red.

For activity evidence, vm_stat exposes swap counters accumulated since boot:

vm_stat

Treat its labels with care. Howard Oakley documented in 2022 that the vm_stat man page defined Swapins and Swapouts backwards relative to Apple’s own source code — and that Swapouts is the number you actually care about. On current macOS the man page (I checked it live while writing this) now matches the source: Swapins are compressed pages swapped back in from disk, Swapouts are compressed pages swapped out to disk. Either way, the honest use is the same: treat changing counters as evidence that pages are moving between memory and disk — not as a byte-perfect swap-write ledger. Howard Oakley, “Tracking swap space: is it wearing out your SSD?”

Bracket the same window with Data Units Written:

start_DUW = first raw Data Units Written value
end_DUW   = second raw Data Units Written value

host-write delta ≈ (end_DUW − start_DUW) × 512,000 bytes

Then compare multiple labeled windows:

• ordinary work with green pressure;
• the same class of work when pressure turns yellow or red;
• a known memory-heavy session;
• a later session after the memory-heavy workload has stopped.

If the device-write slope repeatedly steepens during high-pressure, swap-active windows and relaxes when that pressure is absent, swap is a plausible material contributor. If device writes stay high while pressure is green and swap activity is quiet, another writer is responsible.

That last check prevents a common false attribution. A browser, VM disk image, build, sync client, database, update, or indexing job can be writing heavily at the same time the Mac happens to have swap allocated. Use Activity Monitor’s Disk tab and the process-level method in Which App Is Writing to My Mac’s SSD? before assigning the whole device delta to virtual memory.

Oakley proposes rough triage bands from his own measurements: estimated swap traffic below about 10% of total device writes makes swap a minor contributor; a share around half or more makes memory pressure materially important. Those are his screening heuristics — not Apple limits, not SSD safety thresholds, and not physical-NAND measurements.

For the device-counter conversion and baseline method, see How Much SSD Writing Is Normal on a Mac?. The important part here is the join: pressure and swap activity on one timeline, device writes on the other — the same trend discipline as judging post-update Spotlight indexing.

The honest limits of this measurement

Even careful windowing cannot perfectly isolate swap’s share.

Data Units Written covers the whole device. If a memory-heavy application is simultaneously writing project files, caches, logs, databases, or a scratch disk, both its direct I/O and its swap-related I/O land in the same counter. Time correlation can support a cause; it cannot make competing writers disappear.

The counter is also rounded in 512,000-byte units, so very short windows are noisy. Longer, comparable windows improve the signal — but they still measure host writes, not NAND writes.

Activity Monitor and sysctl vm.swapusage show current allocation, not cumulative turnover. vm_stat adds activity evidence with the interpretation traps above. None of these tools provides a forensic ledger assigning every NVMe data unit to swap. Anyone who sells you a precise “swap wore your SSD by X%” verdict computed from these inputs is inventing the precision.

Hardware access varies too. Current smartmontools has native Darwin NVMe support, but a particular macOS release, Mac, external enclosure, or permission context may not expose the expected health log. smartmontools Darwin NVMe source

Finally, Apple’s public Mac specifications list SSD capacities but no model-specific consumer rated-TBW figure. Do not import the rating of a retail Samsung or Crucial drive and pretend it belongs to Apple’s internal storage. A measured host-write trend is real; a borrowed endurance limit is not.

When sustained swap is worth acting on

Swap is normal memory management. A non-zero allocation with green Memory Pressure is not, by itself, a problem.

The pattern worth acting on is persistent yellow or red pressure, active swapping, and a device-write slope that stays elevated across comparable windows. That means the workload is asking more of physical memory than the machine can comfortably supply, and the disk-backed safety valve is being used repeatedly rather than occasionally.

The practical levers are boring because they work at the cause:

• Close memory-heavy apps you are not actually using.
• Reduce simultaneous VMs, containers, huge browser sessions, or local-model workloads.
• Investigate an app whose memory footprint keeps growing without corresponding work.
• Split unusually heavy jobs instead of running every memory-intensive stage concurrently.
• If the workload is normal for you and chronically produces red pressure, choose more unified memory on the next Mac.

Do not buy a “RAM cleaner.” Forcing useful memory out only gives macOS more reconstruction work later. And do not try to disable swap: Apple documents a fully-integrated virtual memory system “that you cannot turn off; it is always on” — and removing the safety valve is not an endurance remedy; it trades manageable pressure for failed allocations and instability. Apple, “About the Virtual Memory System”

Reducing pressure does not undo writes already made, does not promise a longer SSD life, and predicts nothing. It simply addresses the workload that produced the observed swapping — which is the only lever that was ever real.

Where CoreGuard fits

The manual method above works, and it is complete — Activity Monitor, sysctl, and vm_stat ship with macOS, and smartmontools is free. Its weakness is timing: Activity Monitor shows the moment you happen to be watching, and the device counter only becomes a trend if you remember to take comparable, labeled readings for days.

CoreGuard automates the device-write side of that observation without changing memory management or disk behavior. In Free, the abnormal-write warning is free and it names the process responsible; basic SSD health and danger warnings stay free too. You never pay to learn that write behavior became abnormal.

Pro adds the detailed multi-day per-app write timeline, longer history, and export, plus the SSD-endurance detail and wear trend. For this question specifically, Pro keeps the device-side half of the evidence even when you were not looking; lining it up against the memory-pressure windows you logged is still your manual step — CoreGuard does not record memory pressure — but with the write timeline retained, a brief event and a sustained change stop looking identical.

CoreGuard observes and explains. It does not reclaim RAM, throttle apps, disable swap, delete files, or modify the system — and it will not hand you a fake “swap wore your SSD by X%” verdict, because no honest tool can compute one. The no-purchase method above is the whole method; Pro keeps its evidence after the moment has passed.

How to check whether swap is wearing your SSD

1. Identify the internal disk: Install the free, open-source smartmontools (brew install smartmontools), then run diskutil list internal physical and use the actual internal identifier instead of assuming disk0.
2. Read the memory view: In Activity Monitor → Memory, record Memory Pressure (green/yellow/red), Compressed, and Swap Used; the Terminal equivalent for the allocation fields is sysctl vm.swapusage. These are current-state readings, not lifetime totals.
3. Label the workload and take the device baseline: Write down what the Mac is doing, then run smartctl -a on the identifier from step 1 (disk0 on most Macs — substitute yours) and save the raw Data Units Written value with a timestamp. If the read is denied, rerun just that command with sudo; if the health log still is not exposed, do not invent a value.
4. Observe the same window: Note whether pressure stays green or turns yellow/red, whether Swap Used or the vm_stat swap counters change, and check Activity Monitor → Disk for processes whose Bytes Written is climbing.
5. Close the bracket: Read Data Units Written again and compute the delta × 512,000 = approximate host bytes written. That is every writer on the device during the window — not a swap-only total, and not physical NAND traffic.
6. Correlate, then repeat: Compare equivalent workload windows. High pressure plus active swapping plus a repeatedly steeper device-write slope supports swap as a contributor; high growth without swap activity points at another writer. One Swap Used number proves neither.
7. Act on chronic pressure, not on the gauge: Reduce concurrent memory-heavy work, investigate a growing process, or plan for more unified memory if red pressure is your normal. Do not disable swap, run a memory cleaner, or infer an SSD failure date.

Terms used in this guide

• Swap Used: Activity Monitor’s figure for startup-disk space currently used to swap unused files to and from RAM. A live allocation that rises and falls — not a cumulative write counter.
• Memory Pressure: Apple’s composite gauge of how efficiently memory is serving the workload, determined by free memory, swap rate, wired memory, and file-cached memory. Green/yellow/red, not a percent-full meter.
• Compressed memory: Inactive memory compressed in RAM to make more room. Compression is CPU work in RAM, not an SSD write.
• Data Units Written: The NVMe SMART lifetime host-write counter, in thousands of 512-byte units (1 raw unit = 512,000 bytes). Whole-device, one-way, host-level — physical NAND writes sit below it.
• Write amplification: NAND writes divided by host writes (SNIA). Controller garbage collection and wear leveling make the physical total larger than — and invisible behind — the host counter.
• Unified memory: Apple Silicon’s single memory pool shared by CPU and GPU. Its size is fixed at purchase, which is why chronic red pressure is a next-Mac sizing input.

Frequently asked questions