How to Force Quit an App on Mac: 5 Methods That Work
Summary
The keyboard shortcut ⌘ ⌥ ⎋ opens the Force Quit dialog in under 200ms and covers most frozen app situations on Mac. For helper processes not visible in the dialog, Activity Monitor shows everything with CPU and memory breakdowns. Terminal kill -9 is the nuclear option when all else fails. Force quitting skips cleanup code and loses unsaved data, so treat it as a last resort after the app has been unresponsive for more than 60 seconds.
Knowing how to force quit an app on Mac is one of those things you need exactly when you have no time to look it up. The keyboard shortcut is ⌘ ⌥ ⎋ (Command + Option + Escape): that dialog opens in under 200ms and lists every running app with its current status. If the target shows "(Not Responding)" in red, select it and click Force Quit. Data loss is real, unsaved work in that session is gone. For processes that resist even that method, there are four more paths: Dock right-click, Activity Monitor, a three-modifier shortcut, and Terminal. Here is what each one does, when to reach for it, and what signal it actually sends to the macOS kernel.
⌘ ⌥ ⎋: the Force Quit dialog opens in under 200ms
Press Command + Option + Escape from anywhere on the system, including from inside the frozen application itself. macOS renders this dialog independently of the application event loop, so it fires even when the frontmost app has stopped processing input entirely.
The dialog lists every user-visible app. Frozen processes appear with "(Not Responding)" in red. Select the target, click Force Quit. The system sends SIGKILL to the process. No grace period, no save dialog, no last chance for cleanup code to run.
This is the right move when an application has been spinning for more than 60 seconds, is consuming a sustained 100% CPU, or has become visually unresponsive to all input. If the app is merely slow or showing a beach ball for under 30 seconds, wait. Some apps, particularly those doing disk I/O on spinning drives or completing a large network request, recover without intervention.
Force quit from the Dock without leaving the mouse
Right-click the frozen app's Dock icon while holding Option. The standard "Quit" option changes to "Force Quit". One click. Same SIGKILL result as the keyboard shortcut, no dialog.
This method is useful when your keyboard shortcut muscle memory fails, or when you are already reaching for the mouse to diagnose something in another window. It is strictly equivalent to the ⌘ ⌥ ⎋ path and produces identical results at the kernel level.
Note that if an app's Dock icon has already disappeared, which happens with some crashes, this method is unavailable. Use Activity Monitor or Terminal in that case.
What the spinning beach ball is actually telling you
The spinning wait cursor (colloquially "beach ball" or SPOD: Spinning Pizza Of Death) appears when the main thread of an application has been blocked for more than two seconds. macOS detects that the event loop is not processing incoming events and substitutes the default cursor with the wait indicator.
Common causes: a synchronous network call on the main thread, a disk read from a slow or failing drive, a deadlock between two threads waiting on each other, or a memory pressure event causing the app to swap heavily to disk. The beach ball itself does not indicate a crash. The application is alive but unavailable.
If you see sustained beach ball on a specific app while other apps run normally, check Activity Monitor before reaching for Force Quit. The app may be actively working. If CPU and memory usage are climbing without plateau, it is stuck. If they have flatlined at near-zero, the app is deadlocked and will not recover on its own.
Activity Monitor: finding and killing the right process
Activity Monitor lives at Applications / Utilities / Activity Monitor. Open it with ⌘ Space, type "Activity Monitor", press Return.
The Process Name column shows every running process, not just user-visible apps. The %CPU column is sortable: click it twice to sort descending. A frozen foreground app typically sits at 100% CPU or at 0% if deadlocked. The Real Memory column shows actual RAM consumption. A process showing 8 GB real memory with normal behavior is a leak; force quit and restart.
To kill a process: select it, click the grey stop button (⊗) in the toolbar, then click Force Quit in the confirmation dialog.
Activity Monitor exposes helper processes that do not appear in the standard Force Quit dialog: browser renderer processes, background agents, login items, and system daemons. If Safari has spun up a renderer subprocess that is consuming 400% CPU, Activity Monitor is the only GUI tool that lets you kill it selectively without closing the entire browser.
The "Energy" tab shows 12-hour average CPU usage per app, which is useful for diagnosing what drained your battery overnight rather than what is misbehaving right now.
Terminal: SIGTERM first, SIGKILL only if that fails
Two commands cover 99% of terminal-based force quit needs.
# Send SIGTERM (graceful): asks the app to quit cleanly
kill PID
# Send SIGKILL (hard): uncatchable, immediate termination
kill -9 PIDTo find the PID, run pgrep -x AppName (exact match) or ps aux | grep AppName. Replace AppName with the process name as it appears in Activity Monitor. App names are case-sensitive.
SIGTERM (signal 15, the default) gives the process a chance to finish in-progress operations, flush write buffers, and save state. Well-behaved apps handle SIGTERM and exit gracefully. Frozen apps may not respond to it. If kill PID produces no result after 10 seconds, escalate to kill -9.
SIGKILL (signal 9) is sent directly by the kernel. The process cannot catch it, block it, or ignore it. The kernel terminates the process immediately and reclaims memory. No cleanup code runs. No signal handler fires. The process is gone in under 10ms.
For apps that spawn under their own name: killall AppName sends SIGTERM to every matching process simultaneously. killall -9 AppName sends SIGKILL to all of them.
# Force quit every instance of Xcode
killall -9 Xcode
# Force quit a specific PID found via pgrep
pgrep -x "My App"
# → 12453
kill -9 12453One caution: do not send SIGKILL to system processes (launchd, WindowServer, notifyd, etc.) unless you understand what you are doing. Killing WindowServer logs you out immediately. Killing launchd reboots the machine.
⌘ ⌥ ⇧ ⎋: the foreground shortcut no one mentions
Hold Command + Option + Shift + Escape for approximately one second. macOS force quits the current frontmost application without showing any dialog. No confirmation. No process list. The active app is gone.
This shortcut exists precisely for situations where you cannot move focus away from the frozen app to invoke the standard dialog. It targets only the foreground application. There is no safety prompt.
Use this when: the frozen app has captured mouse input and you cannot click elsewhere, a full-screen app has locked the display, or you want the fastest possible path without any dialog interaction.
Finder is the one exception worth knowing. Force quitting Finder, via any method, causes it to relaunch automatically within a few hundred milliseconds. You cannot permanently close Finder through normal force-quit methods. This is by design: macOS treats Finder as a system process, not a standard application.
What you lose when you force quit, and what you can recover
A force quit skips the normal shutdown sequence. What that means in practice:
Always lost: any data written only to in-memory state and not yet flushed to disk. A document with unsaved edits since the last manual save is gone for that session.
Sometimes recovered: apps that use macOS AutoSave (Pages, Numbers, Keynote, TextEdit in rich text mode) write incremental snapshots to the Versions store. On relaunch, these apps restore to the last autosave checkpoint, typically within a few seconds of your last keystroke.
Often recoverable from crash logs: if the freeze was caused by a bug, the crash report at ~/Library/Logs/DiagnosticReports/ records the state at the moment of termination. Not useful for document recovery, but useful for debugging.
Browser sessions: Chrome, Safari, and Firefox all write session data independently of the system autosave mechanism. Chrome's session recovery works after force quit. Safari restores the tab list. Firefox offers to restore the previous session on relaunch.
Development environments: editors like VS Code write workspace state to disk frequently. Terminal sessions are not recoverable (the process tree and shell history for that session are gone). git stash before you leave anything uncommitted if you suspect an impending crash.
The short version: force quit is safe for browsers and any app using macOS AutoSave. It costs you the current unsaved state in apps that do not autosave. Know which category your app falls into before you reach for the shortcut.
When the whole machine freezes: three exits
If the freeze is system-wide rather than application-specific, the force quit dialog will not appear. Three options, in order of severity:
Force restart via keyboard: Control + Command + Power button. The machine restarts immediately, equivalent to a hard power cycle. Use this when the pointer is unresponsive and no keyboard shortcut produces any visible response.
Power button hold: Hold the power button for 8 to 10 seconds until the machine shuts down. Restart manually. This is the hardware-level equivalent of pulling the plug. File system integrity is preserved on Apple Silicon and on APFS volumes with journaling enabled.
Graceful shutdown via keyboard: Control + Option + Command + Power attempts a clean shutdown by asking running processes to quit before cutting power. This only works if the kernel is still responsive. On a fully frozen system, it may produce no result.
After a force restart, macOS runs a disk check on the next boot. On Apple Silicon Macs with APFS, this completes in under 30 seconds and the data integrity record is clean in all but the most pathological cases (power loss mid-write).