Fix macOS "Application Not Responding — Force Quit?" (Beach Ball)

TL;DR

You see the spinning beach ball (SPOD), macOS pops up "Application Not Responding — Force Quit?", and you need the app back NOW. Open Activity Monitor, sort by CPU or Memory, kill the offending process, then relaunch. The sections below explain exactly why it happens — and how to stop it from coming back.

# Force-quit from Terminal (fastest when the Dock itself is frozen)
kill -9 $(pgrep -x "AppName")

# Or use killall
killall -9 "Slack"

What actually causes the beach ball

The spinning beach ball (SPOD — Spinning Pinwheel of Death) shows up when an app's main thread goes silent for roughly 4–5 seconds. macOS notices the silence and throws up the Application Not Responding — Force Quit? dialog.

The usual suspects:

Runaway process eating 100% CPU — a background helper, a plugin, or the app itself stuck in an infinite loop
Memory pressure — RAM is full, macOS is swapping hard, and the main thread blocks waiting for a page fault to resolve
Disk I/O bottleneck — a slow HDD, a failing SSD, or a stale SMB/NFS mount the app is still trying to reach
Deadlock inside the app — two threads waiting on each other; nothing moves
Corrupted preferences or cache — the app tries to parse a bad plist on startup and just... stops

Step 1 — Find the real culprit first

Don't just force-quit and move on. Find out why or it'll happen again tonight.

# Check top CPU consumers right now
top -o cpu -n 20 -l 1 | head -30

# Check memory pressure
vm_stat | grep -E "Pages (free|active|inactive|speculative|wired|occupied)"

# Check disk I/O (requires sudo)
sudo fs_usage -w -f filesys 2>&1 | grep -i "your_app_name"

Activity Monitor (Applications → Utilities → Activity Monitor) is often faster for a quick visual scan:

CPU tab → sort by % CPU descending — look for anything above 90%
Memory tab → check the "Memory Pressure" graph at the bottom (red means you're in trouble)
Disk tab → look for anything with sudden "Bytes Read" spikes in the hundreds of MB range

Step 2 — Force quit properly

Option A: Force Quit dialog (CMD+OPT+ESC)

Press ⌘ + ⌥ + Esc, select the app marked (Not Responding), click Force Quit. Works for most situations — just don't expect unsaved work to survive.

Option B: Terminal kill (when the UI is frozen solid)

# Get the PID
pgrep -lx "Slack"

# Try a graceful SIGTERM first
kill $(pgrep -x "Slack")

# If it's still alive after 5 seconds, finish it
sleep 5 && kill -9 $(pgrep -x "Slack") 2>/dev/null

Option C: Kill from Activity Monitor

Select the process → click the X button in the toolbar → "Force Quit". Same result as Option A, just a different path.

Step 3 — Fix the root cause

Case: High memory pressure / swapping

# See how much swap is in use
sysctl vm.swapusage

# Free up inactive pages without hurting running apps
sudo purge

Swap usage consistently above 2 GB is a red flag. Either close background apps or accept that you need more RAM. To check for leaks in a specific app:

leaks --atExit -- /Applications/AppName.app/Contents/MacOS/AppName

Case: Corrupted preferences

A bad .plist can freeze an app within seconds of launch, every single time. Back it up, delete it, and let the app rebuild it from scratch.

# Back up and remove the app's preference file
cd ~/Library/Preferences
mv com.company.AppName.plist com.company.AppName.plist.bak

# Clear the preference cache so macOS doesn't serve the stale version
killall cfprefsd

Relaunch the app. If it works, the old plist was the problem — delete the .bak file.

Case: Corrupted app cache

# Remove app-specific cache
rm -rf ~/Library/Caches/com.company.AppName

# Electron apps (VSCode, Slack, Notion) also cache here:
rm -rf ~/Library/Application\ Support/AppName/Cache
rm -rf ~/Library/Application\ Support/AppName/Code\ Cache

Case: Stale network mount causing disk I/O block

An app that reads files from an SMB share or NFS mount will hang indefinitely once that mount goes unreachable. The main thread just sits there waiting for a filesystem response that never comes.

# List mounted network volumes
mount | grep -E "smb|nfs|afp"

# Force-unmount the stale share
diskutil unmount force /Volumes/MyShare
# or
sudo umount -f /Volumes/MyShare

Case: Runaway helper process (very common in Electron apps)

# Find all child processes spawned by the app
pstree -p $(pgrep -x "Slack") 2>/dev/null || pgrep -P $(pgrep -x "Slack")

# Kill the helper, not the main app
kill -9

Case: Spotlight indexing the app's data folder

Spotlight's mds/mdworker processes can trigger massive disk I/O when they decide to reindex an app's data directory — often right after an update.

# Confirm mds is the CPU hog
top -o cpu | grep mds

# Pause indexing temporarily
sudo mdutil -a -i off
# Re-enable after a few minutes
sudo mdutil -a -i on

For a permanent exclusion: System Settings → Siri & Spotlight → Spotlight Privacy → drag the folder in.

Step 4 — Capture a diagnostic before you kill it

Recurring freezes deserve a proper investigation. Grab a spindump before force-quitting — it captures a full stack trace of every thread at the moment of freeze, which is exactly what you need to file a useful bug report.

# Capture spindump of frozen app (saved to /tmp/)
sudo spindump AppName -o /tmp/AppName_spindump.txt

# Or sample the process for 10 seconds
sample $(pgrep -x "AppName") 10 -file /tmp/AppName_sample.txt

Open the file and search for repeated stack frames. That repetition is your deadlock or hot loop.

Verification

Once you've applied a fix, watch the app for 60 seconds before declaring victory:

# Track CPU and memory in real-time
top -o cpu -s 2 -l 30 | grep -i "appname"

# Watch memory pressure — refresh every 5 seconds
vm_stat 5

The Memory Pressure graph in Activity Monitor should stay green. Yellow is a warning. Red means the freezes will keep coming until you either close apps or add RAM — no fix will hold in that state.

When nothing works — the nuclear option

Entire macOS UI is frozen? Mouse moves but nothing responds? SSH in from another machine and restart the session:

# Kill the window server — this ends your session immediately
ssh user@your-mac
sudo killall -KILL loginwindow

You'll be logged out and the session restarts cleanly. Unsaved work is gone, but it's far faster than a hard power cycle and it avoids filesystem corruption.

Prevent it from happening again

Keep at least 10–15% free disk space — macOS uses your SSD as virtual memory swap; a nearly full disk means slow swap, which means beach balls
Run sudo periodic daily weekly monthly occasionally to clear system caches that build up over time
Update your apps — a surprising number of ANR bugs are fixed in the latest version and most users never notice because they never update
For Electron apps (VSCode, Slack, Notion), check the release notes for your current version; memory leaks in Electron are common and usually patched within 1–2 releases
Beach balls only on battery? System Settings → Battery → Low Power Mode throttles the CPU hard. Turn it off during any heavy work session.